From 0d74bdaf0c39feb8ec303dbbdbcadba70e46eecb Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Mon, 30 Sep 2013 10:14:22 +0200 Subject: Fixed #21134 -- Prevented queries in broken transactions. Backport of 728548e4 from master. Squashed commit of the following: commit 63ddb271a44df389b2c302e421fc17b7f0529755 Author: Aymeric Augustin Date: Sun Sep 29 22:51:00 2013 +0200 Clarified interactions between atomic and exceptions. commit 2899ec299228217c876ba3aa4024e523a41c8504 Author: Aymeric Augustin Date: Sun Sep 22 22:45:32 2013 +0200 Fixed TransactionManagementError in tests. Previous commit introduced an additional check to prevent running queries in transactions that will be rolled back, which triggered a few failures in the tests. In practice using transaction.atomic instead of the low-level savepoint APIs was enough to fix the problems. commit 4a639b059ea80aeb78f7f160a7d4b9f609b9c238 Author: Aymeric Augustin Date: Tue Sep 24 22:24:17 2013 +0200 Allowed nesting constraint_checks_disabled inside atomic. Since MySQL handles transactions loosely, this isn't a problem. commit 2a4ab1cb6e83391ff7e25d08479e230ca564bfef Author: Aymeric Augustin Date: Sat Sep 21 18:43:12 2013 +0200 Prevented running queries in transactions that will be rolled back. This avoids a counter-intuitive behavior in an edge case on databases with non-atomic transaction semantics. It prevents using savepoint_rollback() inside an atomic block without calling set_rollback(False) first, which is backwards-incompatible in tests. Refs #21134. commit 8e3db393853c7ac64a445b66e57f3620a3fde7b0 Author: Aymeric Augustin Date: Sun Sep 22 22:14:17 2013 +0200 Replaced manual savepoints by atomic blocks. This ensures the rollback flag is handled consistently in internal APIs. --- docs/topics/db/transactions.txt | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt index 4b2fa88ad6..b232d26b2c 100644 --- a/docs/topics/db/transactions.txt +++ b/docs/topics/db/transactions.txt @@ -163,20 +163,31 @@ Django provides a single API to control database transactions. called, so the exception handler can also operate on the database if necessary. - .. admonition:: Don't catch database exceptions inside ``atomic``! - - If you catch :exc:`~django.db.DatabaseError` or a subclass such as - :exc:`~django.db.IntegrityError` inside an ``atomic`` block, you will - hide from Django the fact that an error has occurred and that the - transaction is broken. At this point, Django's behavior is unspecified - and database-dependent. It will usually result in a rollback, which - may break your expectations, since you caught the exception. + .. admonition:: Avoid catching exceptions inside ``atomic``! + + When exiting an ``atomic`` block, Django looks at whether it's exited + normally or with an exception to determine whether to commit or roll + back. If you catch and handle exceptions inside an ``atomic`` block, + you may hide from Django the fact that a problem has happened. This + can result in unexpected behavior. + + This is mostly a concern for :exc:`~django.db.DatabaseError` and its + subclasses such as :exc:`~django.db.IntegrityError`. After such an + error, the transaction is broken and Django will perform a rollback at + the end of the ``atomic`` block. If you attempt to run database + queries before the rollback happens, Django will raise a + :class:`~django.db.transaction.TransactionManagementError`. You may + also encounter this behavior when an ORM-related signal handler raises + an exception. The correct way to catch database errors is around an ``atomic`` block as shown above. If necessary, add an extra ``atomic`` block for this - purpose -- it's cheap! This pattern is useful to delimit explicitly + purpose. This pattern has another advantage: it delimits explicitly which operations will be rolled back if an exception occurs. + If you catch exceptions raised by raw SQL queries, Django's behavior + is unspecified and database-dependent. + In order to guarantee atomicity, ``atomic`` disables some APIs. Attempting to commit, roll back, or change the autocommit state of the database connection within an ``atomic`` block will raise an exception. -- cgit v1.3