Opened 3 years ago

Last modified 3 years ago

#24446 new Bug

ATOMIC_REQUESTS add extra queries if the view was already in a transaction

Reported by: Mathieu Pillard Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


ATOMIC_REQUESTS documentation says it wraps the view in a transaction, but since it actually only calls atomic(), it will actually use savepoints if the view was already in a transaction when make_view_atomic() is called.

This matters in tests, because TestCase opens a transaction by default. With the old TransactionMiddleware, using a regular TestCase and assertNumQueries(0) on views that did not make db queries of their own worked, with ATOMIC_REQUESTS 2 queries are seen, breaking any tests relying on this behavior.

Not sure whether to consider this a bug in the implementation or in the documentation only. I certainly didn't expect all my assertNumQueries() tests to fail when switching to ATOMIC_REQUESTS.

Attached is a patch demonstrating the issue.

Attachments (1)

patch (2.3 KB) - added by Mathieu Pillard 3 years ago.
Test demonstrating the issue

Download all attachments as: .zip

Change History (3)

Changed 3 years ago by Mathieu Pillard

Attachment: patch added

Test demonstrating the issue

comment:1 Changed 3 years ago by Aymeric Augustin

I discussed this with diox yesterday on IRC and suggested this patch which appears to fix the issue:

diff --git a/django/core/handlers/ b/django/core/handlers/
index e40eb2f..92ad394 100644
--- a/django/core/handlers/
+++ b/django/core/handlers/
@@ -78,7 +78,7 @@ class BaseHandler(object):
         for db in connections.all():
             if (db.settings_dict['ATOMIC_REQUESTS']
                     and db.alias not in non_atomic_requests):
-                view = transaction.atomic(using=db.alias)(view)
+                view = transaction.atomic(using=db.alias, savepoint=False)(view)
         return view
     def get_exception_response(self, request, resolver, status_code):

I think this change is for the better, however there's a potential for backwards incompatibility. If some developers went through the pain of adding 2 to all their assertNumQueries, forcing them to substract 2 again isn't nice...

That said, if I remember correctly, I had found a solution during the transaction refactor to avoid breaking assertNumQueries, so I'm not sure why diox is seeing this issue.

comment:2 Changed 3 years ago by Tim Graham

Triage Stage: UnreviewedAccepted
Note: See TracTickets for help on using tickets.
Back to Top