Opened 10 years ago
Last modified 10 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: | dev |
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 |
Description
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)
Change History (3)
by , 10 years ago
comment:1 by , 10 years ago
I discussed this with diox yesterday on IRC and suggested this patch which appears to fix the issue:
diff --git a/django/core/handlers/base.py b/django/core/handlers/base.py index e40eb2f..92ad394 100644 --- a/django/core/handlers/base.py +++ b/django/core/handlers/base.py @@ -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 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
Test demonstrating the issue