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/fd81d210-a2d6-4e7a-9eb0-d3f8f078a032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to