> > I'll open a ticket about the docs later today. https://code.djangoproject.com/ticket/21134
> Let me know if you think it can be improved. > That looks nice and explicit to me. I'm OK with trying to to raise exceptions when making a query and > get_rollback returns True. I'm not sure it's doable; patch welcome ;-) How about this: https://github.com/RichardOfWard/django/commit/cb46c75db275db59b54511c090286255bd9cc46d It raises the same error that PostgreSQL would raise if you try and do any SQL when in a transaction with 'needs_rollback' is True. I've tested this with PostgreSQL, MySQL and SQLite3, and they all now behave in the same way that PostgreSQL behave currently (I'm running the test suite at the moment, its taking a while). *Any* exception bubbling from atomic(savepoint=False) block will cause this > issue So for example: with transaction.atomic(): try: with transaction.atomic(savepoint=False): MyModel(foo=1).save() raise Exception("whatever") except Exception: pass MyModel(foo=2).save() print MyModel.objects.all() Prints out '[]' (rather than raising an exception) with any database. With the above patch an exception is instead raised when you try to do the second save. However... You say in your docs patch that savepoints are cheap, 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?). 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, allow Django+MySQL/SQLite3 to be used like I was trying to originally (for better or worse), and it would mean the snippet I posted above would commit the outer transaction instead of silently rolling it back, which is what a casual reading of the snippet would suggest might happen (Removing the option for savepoint=False would have the same effect). Richard. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
