On Thu, Dec 1, 2011 at 6:38 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote:
> On Nov 30, 2:26 pm, Kääriäinen Anssi <anssi.kaariai...@thl.fi> wrote: > \> The other way is storing old_pk in model._state, and compare the PK to > > that when saving. If changed, error. This would work best if there was a > > NoneMarker object for the cases where there is no PK from DB, so you > could > > solve #14615 easily, too. > > I tried the second approach, and the mutable object based fields makes > it basically unworkable. The problematic case turned out to be > FileField. Now, that could be hacked around, but other inplace-mutable > fields do exist, at least in user code. > That's really too bad; I was hoping that that approach would work. (Also, I really hope nobody is using a FileField for a primary key ;) ) Is the problem here that we can't reliably tell whether the data that is going out to the DB layer has changed? I would think that no matter how the data is modified (in-place vs. setattr), that the one thing we could rely on, and the one thing that actually matters in this situation, is the serialised representation of the data. For a FileField, that would be the filesystem path (editing the file in place without changing the path wouldn't give you the duplication problems that you are having); for an IntegerField, it's just the number itself. It should be the case that, no matter what sort of python magic a particular developer has added, it is equivalence at the SQL level that is causing problems. Maybe it's because I haven't tried to hack at this myself, but I can't see why storing a copy of the PK fields DB-representation on load, and checking them on save, isn't sufficient. There is a memory cost, but it should be small, unless you have very large fields for primary keys in your database, in which case you are already suffering from them, certainly :) -- Regards, Ian Clelland <clell...@gmail.com> -- 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.
