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 defensively anyway, that is, leave a consistent state regardless of what methods are or aren't called. 2) The goal of ATOMIC_REQUESTS is to prevent inconsistent modifications of the database in views. Since middleware run for every view, they shouldn't introduce inconsistencies no matter what happens. 3) Most middleware don't touch the database. Database queries that run at every request aren't good for overall performance. 4) For lack of a better reason, keeping the database transactions short is more efficient. 1) and 2) really boil down to the fragility of how Django executes middleware. Not including middleware in transactions reduces the risk that developers will make incorrect assumptions. 3) and 4) don't apply to your use case. I looked at how reversion is implemented but I don't understand it sufficiently well to give advice. This isn't a satisfying answer but I hope it helps. -- Aymeric. 2015-02-03 9:59 GMT+01:00 Thomas Güttler <[email protected]>: > 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. > > We would like to understand why that is the default behavior now and we > are supposed to re-organize our code base to work with that changes. > > What is the rationale behind middlewares not being executed within the > same transaction as the view function? > > Furthermore, decorating all view functions as suggested here > http://django-reversion.readthedocs.org/en/latest/api. > html#revisionmiddleware is quite not feasible for large projects. > Especially given that reversion is not the only middleware that needs to be > executed within the same transaction as the view function. It would > basically mean that each view function needs to be decorated potentially n > times. > > > We understand that transactions might effect performance, thus lesser > transactions being in a transaction means faster execution. However, > shouldn't there be the possibility to include distinct middlewares into the > view transaction? > > > Regards, > Thomas Güttler > > -- > Thomas Güttler > http://thomas-guettler.de/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/54D08DF5.8080606%40tbz-pariv.de. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mW9NTFmMeUUrwYtGOgd_xDr2M_kpzA4r%3DbPLVy5m14ZTw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
