On Thursday, October 24, 2013 11:40:37 PM UTC+3, Anssi Kääriäinen wrote:
> Here is the full list of changes that potential for breaking user code: > - If related object's default manager has default filtering, then > .remove() and .clear() will not clear those items that are filtered out. > - Reverse ForeignKey .remove() will not use .save() - it will use > .update() - so no model save signals, and overridden model.save() is > missed, too. > - GFK.remove() and GFK.clear() will use queryset.delete() - so > model.delete() is not called anymore (signals are sent in this case as > QuerySet.delete() does that). > > Loic's list of fixes & changes is also a good summary of this ticket: > https://code.djangoproject.com/ticket/21169#comment:9 > I haven't figured any other way to deal with this ticket than just committing the changes. I hope the backwards incompatibilities aren't that severe. The second issue above seems to be the hardest one for users - if you relied on model save signals in your code the code will now be broken *and* you don't have any viable upgrade path if you relied on post_save signal. I am considering addition of pre/post update signals. These signals would give an upgrade path for those who are hit with backwards incompatibility problems from #21169. The signals would of course be a good addition for those who happen to need them. The signals shouldn't affect the performance of your project if you don't use the signals. The idea is that pre_update listeners get a queryset that isn't executed. Accessing that queryset might be costly, but if it isn't accessed, there isn't much cost of adding a pre_update signals. For post_update the signal handler would be given a list of PK values (the original queryset doesn't work for post_update, the update might cause different instances to be returned than was updated, consider qs.filter(deleted=False).update(deleted=True)) The problem here is that if you are updating a lot of rows (millions+), then even fetching the pk value can be too much. Maybe an update(__signals=False) flag could be added? It is also easy to optimize away the pk fetching if there aren't any post_update listeners. Any objections to committing the fixes for https://code.djangoproject.com/ticket/21169? Any feedback for pre/post_update idea? - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e37a4bb8-5920-4cc7-adaf-de525a2343d7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
