I am suggesting the following PK change behavior will be deprecated in
1.4. The problem is this:
class SomeModel:
name = models.CharField(max_length=20, primary_key=True)
s = SomeModel(name='foo')
s.save()
s.name='bar'
s.save()
At this point you end up with both 'foo' and 'bar' objects in the DB.
This is counter intuitive. However this isn't that bad currently, as
natural primary keys aren't too common. I do hope that multipart
primary keys do get into Django some day. If you have a model:
class User:
firstname = models.CharField
lastname = models.CharField
pk = (firstname, lastname)
then if trying to change an users name in the most obvious way:
u = User.objects.get(firstname='Anssi', lastname='Kääriäinen')
u.firstname='Matti'
u.save()
results in both Anssi and Matti users in the DB, it is simply a bad
API. So I suggest deprecating this behavior in 1.4. Django doesn't
need to be intelligent enough to update & cascade the PK change,
although that would be a nice feature later on. Just erroring out on
PK change would be good enough.
The reason for doing the deprecation now is that it would be nice that
this behavior is already removed when multicolumn primary keys are
introduced into Django.
There is a ticket related to this: #2259.
- 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.
