Hello, > On 18 Nov 2021, at 11:11, Florian Apolloner <f.apollo...@gmail.com> wrote: > > FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions as > needed :)
Investing engineers' time into evaluating the exact transactional integrity requirements of every view may be appropriate in some contexts. Getting a blanket safeguard from ATOMIC_REQUESTS can be a fair tradeoff in other contexts. Engineer time is expensive. PostgreSQL horsepower can be pretty cheap on low or even medium traffic websites, which are a substantial part of Django's target audience. On these websites, it can be entirely reasonable to pay a limited cost for ATOMIC_REQUESTS and to get the benefit that every view succeeds completely or fails completely. Also you don't depend on engineers getting the analysis right every time, including when they make a change — the situation that triggered this discussion in the first place. > Honestly long transactions are imo bad, one should evaluate what the view > needs and then act accordingly. Since most views on most websites are short, it isn't completely bonkers to use a blacklist approach, that is, to review the situation closely on long views and apply non_atomic_requests appropriately. I'm not trying to disagree for the sake of disagreement; I'm just trying to bring some contextual awareness and avoid the "core devs say ATOMIC_REQUESTS is bad" effect. I hope we can agree on this? Finally — yes, I know that my implementation of this feature is a wormhole across layers. I won't even try to justify it. I wish we had something better but we haven't found that yet. -- Aymeric. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16779272-37F9-4BB6-A5F7-4CE5B226E2A9%40polytechnique.org.
