As MIDDLEWARE supports decorator-like objects you could simply add
`django.db.transaction.atomic' to it and you'd get each request wrapped in
a transaction.
Note that this will only start a transaction on the `default` database,
just like the old TransactionMiddleware use to do.
Simon
Le
Starting with Django 1.10 you can write a TransactionMiddleware again, and
we will probably ship one again.
On Tuesday, May 10, 2016 at 2:07:30 AM UTC+2, Kevin Tran wrote:
>
> Thomas, did you ever find a solution to your problem? I'm having similar
> thoughts and am looking for an answer.
>
>
Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran:
>
> Thomas, did you ever find a solution to your problem? I'm having similar
> thoughts and am looking for an answer.
>
>
Carl Meyer has worked out an enhancement proposal, here is the
pull-request:
Thomas, did you ever find a solution to your problem? I'm having similar
thoughts and am looking for an answer.
On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>
>
>
> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
> > I'd really like to be able to define middlewares that
Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called
I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for given middleware, and
this makes it impossible to
On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote:
>
> Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be
> accepted?
>
Most likely not since one of the reasons why @atomic isn't applied via a
middleware (which would then include the middlewares after it) is
Thank you very much for your fast reply.
Our team discussed the solutions we see. At the moment we see this upgrade:
- We stay with the older django version, and don't use atomic for the next
months.
- We provide a patch for django to provide
settings.MIDDLEWARES_INSIDE_TRANSACTION
- I
Hi Thomas,
Both ways had advantages and drawbacks. Eventually I chose to include only
the view function in the transaction for the following reasons.
1) Django never made any guarantees about which process_* methods of
middleware would be called. Therefore every middleware must implemented
Dear Django developers,
we currently have the following issue when upgrading from Django 1.5 to Django 1.6:
https://github.com/etianen/django-reversion/issues/268
As it seems, since Django 1.6, middlewares are not supposed to be executed within the same transaction as the view
function is.
10 matches
Mail list logo
