> Le 21 sept. 2013 à 15:53, Richard Ward <[email protected]> a écrit : > > You say in your docs patch that savepoints are cheap
Truth be said, I haven't run benchmarks. > so what is transaction.atomic(savepoint=False) for? is it just for > performance, or is more like an assertion that we are definitely in a > transaction (or both?). It's mostly for performance. Ask Anssi for details. There a second, more practical, reason; read below. > At present the decision to rollback or commit is based on whether there is a > current exeption and whether needs_rollback is True. If instead this were > just based on whether there is a current exception (getting rid of > needs_rollback), then exceptions bubbling from inside a > transaction.atomic(savepoint=False) would still cause a rollback, and > catching an exception (hiding it from the context manager) would lead to a > commit (or at least an attempt to commit). This would leave > Django+PostgreSQL's behaviour unchanged You may be right. I'm not sure. This code is tricky. Such assertions routinely take more than 10 hours of work to confirm. > Removing the option for savepoint=False would have the same effect It would have the drawback of breaking everyone's assertNumQueries because of the extra savepoints introduced by Django. This would be very hostile to people porting large, well-tested code bases. -- Aymeric (mobile). -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
