[Django] #24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction

8 views
Skip to first unread message

Django

unread,
Mar 4, 2015, 1:16:11 PM3/4/15
to django-...@googlegroups.com
#24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction
----------------------------------------------+--------------------
Reporter: diox | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
`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.

--
Ticket URL: <https://code.djangoproject.com/ticket/24446>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Mar 4, 2015, 1:34:07 PM3/4/15
to django-...@googlegroups.com
#24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction
-------------------------------------+-------------------------------------

Reporter: diox | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


Comment:

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.

--
Ticket URL: <https://code.djangoproject.com/ticket/24446#comment:1>

Django

unread,
Mar 5, 2015, 6:09:09 AM3/5/15
to django-...@googlegroups.com
#24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction
-------------------------------------+-------------------------------------

Reporter: diox | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timgraham):

* stage: Unreviewed => Accepted


--
Ticket URL: <https://code.djangoproject.com/ticket/24446#comment:2>

Reply all
Reply to author
Forward
0 new messages