On Dec 3, 5:03 am, Carl Meyer <c...@oddbird.net> wrote: > Did we gain support for multi-column PK recently and I missed it? Or is > this just a hypothetical example assuming such support is added in the > future?
Yes, this is a hypothetical example, inspired by the GSoC work on multicolumn primary keys [https://github.com/koniiiik/django]. This thread started with the multicolumn PK example, and the point of the thread is that when Django gets multicolumn primary keys, the current behavior is more likely to bite users. Doing the obvious thing when trying to update the primary key will results in duplicates in the DB. At the moment this is not that big of a problem, as natural primary keys aren't that common. > > The idea would be to raise exception from the second save (deprecation > > warning at this point). A way to get the current behavior is needed too, but > > the user should explicitly request that. > > Hmm, I'm not so sure this is really a problem, or enough of a problem to > warrant making people change currently-working code. If you use > non-sequence PKs (and usually you shouldn't), you should be aware of > what you're doing. > > If the real problem is the way the admin exposes the possibility of > accidental cloning to end users, maybe we should be looking at a simpler > admin-level fix (like not making PK fields editable by default)? Admin should be fixed [#2259]. Making PK fields non-editable in ModelForms would be good, too. Is it OK to consider the current ModelForm behavior a bug, or will it need a deprecation cycle? In my opinion admin getting this wrong is a strong indication about how non-intuitive the API is. It is OK that Django doesn't support primary key updates. But if it doesn't support update of PK, then lets error out on primary key change. Current behavior of .save() is actually: "save the object to DB, except when PK has changed, then do a clone". That is a bad API for natural primary keys. About breaking current code: my intention is to have a flag to .save() which would allow current code to work. .save(clone=True) would get current behavior back. Setting the PK to None and doing a save will work for AutoField PKs. I opened a ticket for this: https://code.djangoproject.com/ticket/17332 - 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.
