On 3 mars 2013, at 21:37, Aymeric Augustin <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
