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 merc
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.
>
> O
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: https://github.com/django/django/
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 actu
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 for
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 im
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 t
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 hope
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
defens
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
