On 3 mars 2013, at 21:37, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote:
> Part 2 of the plan is more ambitious — it's about improving the transaction > APIs. Here's the general idea. > > I'd like to add an @atomic decorator that: > - Really guarantees atomicity, by raising an exception if you attempt > commit within an atomic block, > - Supports nesting within an existing transaction, with savepoints. This is now implemented: https://github.com/django/django/pull/873 The test suite passes under SQLite and almost under PostgreSQL (two failures). Code reviews, docs reviews, and smoke tests would help a lot at this stage. Checkout my branch, run your apps, tell me what breaks! In the mean time, I discovered that it's impossible to implement TransactionMiddleware reliably as a middleware, because there's no guarantee that process_response or process_exception will be called. Currently, Django has a safety net: the request_finished signal triggers a rollback if the middleware failed. In other words the HTTP layer is already, to some extent, coupled with the transaction management. Besides, TransactionMiddleware doesn't guarantee much. For instance, using commit_on_success as a context manager in a view breaks it by committing the transaction prematurely. So part 3 of the plan is to replace TransactionMiddleware by something based on transaction.atomic that actually works. For lack of a better idea, I'm considering deprecating the middleware and replacing it with a setting. This doesn't qualify as loose coupling; better ideas welcome! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
