On Dec 3, 7:18 pm, Carl Meyer <c...@oddbird.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/03/2011 02:13 AM, Anssi K ri inen wrote: > > > 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? > > I think it would need a deprecation cycle. People certainly could be > making use of the current behavior (and there would need to be a way to > get the PK field back into the form, e.g. by explicitly listing it in > "fields"). Excluding PK from ModelForm by default isn't clearly fixing a > bug, it's more protecting people from unintuitive behavior. > > (Note that in admin we have the option to display it read-only by > default; ModelForm has no such feature, we'd have to exclude it entirely > by default).
This turns out to be a show-stopper. I think that in admin we could just make the field non-editable when editing an object, but editable when saving a new object. Save-as-new would be a problem, but probably some workaround could be found. But for ModelForms, what to do? You would want to have the same behavior as in admin: editable when adding, but non-editable when editing an existing object. But the problem is, we do not have the ability to show the value as non-editable. Could this be implemented by a html attribute editable="false"? Ugly, but should work for most cases. I do agree this needs a deprecation cycle. > > 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. > > So what about admin users who are currently relying on this behavior as > a way to clone objects with natural PKs (given that the > save-and-add-another button is useless with natural PKs unless you can > explicitly give the value for the new row)? Javascript magic? save-as-new disabled for natural PKs, instead you get a "copy" button which opens another window? In other words, good ideas welcome... - 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.
