@Anssi, Perhaps we could use your approach above, except using rowids instead of primary keys? Many SQL flavors support retrieving the rowids of the created/updated rows within the same query as a bulk create/update (e.g. OUTPUT or RETURNING).
Greg On Thursday, April 6, 2017 at 12:53:55 AM UTC-5, Anssi Kääriäinen wrote: > > On Friday, March 31, 2017 at 10:50:54 AM UTC+3, Todor Velichkov wrote: >> >> @Anssi, thank you for your response. >> I really haven't think about threat safety, but maybe its because in our >> specific usage it's close to impossible to happen. >> >> What do you think about this: >> 1) Put everything into a transaction >> 2) Before update, count the queryset. >> 3) Fire the pre_update with the queryset, and the count. >> 4) Do the actual update -> get the updated rows >> 5) Assert the updated rows is equal to the queryset.count(). >> 6) Revert the transaction if there is a difference. >> >> No pk fetching, this is left to the be implemented by the listener if he >> needs it. >> > > I'm afraid this won't work well enough. It does work for many use cases, > but in cases where concurrency is an issue, you'd get some loud failures, > and worse, you could get cases where things work silently wrong (one item > removed, one added concurrently). These cases would be near-impossible to > debug. > > The reason why we don't have update signals is that it's hard to find a > solution that allows users to run actions when an instance is updated, > works correctly in concurrent cases and with large amount of objects and > doesn't turn bulk update in to a loop of save() calls. > > Maybe the best approach is to look for a solution where users can > customise update behaviour for remote models if they so wish. Then you > could write your own update signals solution, one that doesn't need to care > about all of the above constraints. > > - Anssi > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/08303c25-96a8-4aa0-b325-ef5dc91ed8d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
