[Django] #26043: Missing Middlewares for Changing Transaction Parameters
Django
-------------------------------+--------------------
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
We are upgrading from Django 1.7 to Django 1.8. We noticed, we cannot
perform things:
{{{
connection.cursor().execute('SET LOCAL my_variable TO %d' % var)
}}}
in some of our Middlewares anymore due to the missing
TransactionMiddleware.
We have more than 2,000 views (some of them created dynamically) , so
decorating them manually is not a practical nor secure solution.
Currently, we patch {{{BaseHandler.make_view_atomic}}} to handle this but
its weird that there is not default way to insert custom code in between
starting a transaction and the actual execution of a view.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
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 srkunze):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> We are upgrading from Django 1.7 to Django 1.8. We noticed, we cannot
> perform things:
> {{{
> connection.cursor().execute('SET LOCAL my_variable TO %d' % var)
> }}}
> in some of our Middlewares anymore due to the missing
> TransactionMiddleware.
>
> We have more than 2,000 views (some of them created dynamically) , so
> decorating them manually is not a practical nor secure solution.
>
> Currently, we patch {{{BaseHandler.make_view_atomic}}} to handle this but
> its weird that there is not default way to insert custom code in between
> starting a transaction and the actual execution of a view.
New description:
We are upgrading from Django 1.7 to Django 1.8. We noticed, we cannot
perform things like:
{{{
connection.cursor().execute('SET LOCAL my_variable TO %d' % var)
}}}
in some of our Middlewares anymore due to the missing
TransactionMiddleware.
We have more than 2,000 views (some of them created dynamically) , so
decorating them manually is not a practical nor secure solution.
Currently, we patch {{{BaseHandler.make_view_atomic}}} to handle this but
its weird that there is no default way to insert custom code in between
starting a transaction and the actual execution of a view.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:1>
Django
Reporter: srkunze | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* status: new => closed
* resolution: => invalid
Comment:
Hi srkunze, [https://docs.djangoproject.com/en/1.9/internals/deprecation
/#deprecation-removed-in-1-8 TransactionMiddleware] has been deprecated
[https://docs.djangoproject.com/en/1.9/releases/1.6/#transaction-
management-apis since Django 1.6] in favor of the
[https://docs.djangoproject.com/en/1.9/topics/db/transactions/#tying-
transactions-to-http-requests ATOMIC_REQUESTS] settings which should do
exactly what you are expecting.
Please reopen if adding `ATOMIC_REQUESTS: True` to your `DATABASES`
setting aliases doesn't work for your.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:2>
Django
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: closed => new
* resolution: invalid =>
Comment:
I believe the transaction created by ATOMIC_REQUESTS only applies to the
view, not to middleware.
As a consequence it may not solve the reporter's problem (but I'm not sure
I understood it entirely).
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:3>
Django
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by srkunze):
> I believe the transaction created by ATOMIC_REQUESTS only applies to the
view, not to middleware.
Exactly. That's why we monkey patched {{{ BaseHandler.make_view_atomic
}}}.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:4>
Django
-------------------------------+------------------------------------
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* type: Bug => New feature
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:5>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by srkunze):
@timgraham I changed the code example to pass {{ db }}} into the wrapper
function.
Please, note we would need to execute **arbitrary code** (not just
queries) between start of a transaction and all views.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:6>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by guettli):
Just for the records. The same topic was discussed in February 2015:
https://groups.google.com/forum/#!topic/django-developers/uW5Ogio8QBc
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:7>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
At that point I would suggest to write your own transaction middleware
that does:
{{{
self.atomic = transaction.atomic()
self.atomic.__enter__()
}}}
in the request phase and
{{{
self.atomic.__exit__(...)
}}}
in the response phase.
Django has gotten away with roughly the equivalent of this until version
1.6.
Sorry, I'm not proud of that...
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:8>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by srkunze):
@aaugustin We'd like to use the ATOMIC_REQUESTS feature unbroken as is.
A simple hook, as timgraham suggested, would fit the bill.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:9>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
But that would increase complexity to an area that is already poorly
designed (by my fault), thus making it even harder to refactor in the
future :-/
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:10>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
If I understand correctly, the [https://github.com/django/django/pull/5591
new middleware proposal] would allow implementing a
`TransactionMiddleware` with the same functionality as `ATOMIC_REQUESTS`
with the benefit that you could also have other middleware to run queries
like requested here, so that would solve this ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:11>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by apollo13):
@tim: Yes that was the main motivation of the middleware refactor. We
should have `TransactionMiddleware` in 1.10 again.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:12>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by apollo13):
* cc: apollo13 (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:13>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by guettli):
The new "DEP 0005: Re-thinking middleware" would solve this issue:
>..... It also allows more powerful idioms that aren't currently possible,
like wrapping the call to get_response in a context manager (e.g.
transaction.atomic) or in a try/finally block.
Source: https://github.com/django/deps/blob/master/draft/0005-rethinking-
middleware.rst
A big thank you to Carl Meyer, the author of DEP 0005.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:14>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by TZanke):
* cc: tzanke@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:15>
Django
-------------------------------+------------------------------------
Type: New feature | Status: closed
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
Closing in light of the middleware refactor.
--
Ticket URL: <https://code.djangoproject.com/ticket/26043#comment:16>