"""
Is this referring exclusively to natural, or user-specified primary key
columns? Despite Luke's reference to nullable primary keys (are these even
allowed by SQL?), a common idiom for copying objects is this:
"""
Not allowed by SQL specification, but many databases do allow them (source
wikipedia).
"""
obj.pk = None
obj.save()
I have used use this pattern in more instances than I can remember; whether for
duplicating objects, or for making new variants of existing objects. I would
hate to see the behaviour deprecated, or worse, for the old object to simply
get reassigned a new (or null) id.
"""
If nullable primary keys are going to be allowed, then the above can not work.
You would need to use NoneMarker in there, or .save() would need a kwarg for
backwards compatibility mode. obj.clone() is still another possibility. Maybe
nullable primary keys should be forbidden?
"""
For changing natural primary key fields, I would prefer to see a pattern like
this:
class User:
firstname = models.CharField
lastname = models.CharField
pk = (firstname, lastname)
u = User.objects.get(firstname='Anssi', lastname='Kääriäinen')
u.firstname='Matti'
u.save(force_update=True)
"""
That is a possibility, although currently that has well defined meaning: try to
update the object with pk ('Matti', 'Kääriäinen'), error if it does not exist
in the DB.
"""
(specifically, with the force_update parameter being required for a PK change).
Then, as long as we store the original PK values, the object can be updated in
place. A bare save() would work just as currently changing the id field does --
create a new row if possible, otherwise, update the row whose PK matches the
new values.
"""
IMHO forbidding creation of a new object while leaving the old object in place
when calling save() is needed. Current behavior is unintuitive. One clear
indication of this being unintuitive is that even Django's admin does not get
it right. If bare save() will be deprecated, then an upgrade path for current
uses is needed. A new kwarg for save (old_pk=None would be a possibility) or
obj.clone() would be needed.
Solving all these problems before 1.4 seems hard.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
