On 22 sept. 2013, at 23:09, Shai Berger <[email protected]> wrote:
> The code base I mentioned earlier relies mostly on TransactionMiddleware, but
> does have some explicit commit_on_success's etc. (it's Django 1.4 based, so
> no
> @atomic or anything like it).
I'm genuinely interested in making it as easy as possible to switch to the new
transaction management.
If you weren't using the transaction middleware, in 1.6 you would be in
autocommit mode and we wouldn't have this discussion at all.
Once you switch to ATOMIC_REQUESTS, assuming we go with the current
plan — and it still looks like the best compromise at this point — you'll have
to insert an extra atomic block to guarantee a clean rollback.
try:
do_stuff_in_db()
except DatabaseError:
do_more_stuff_in_db()
must be changed to:
try:
with transaction.atomic():
do_stuff_in_db()
except DatabaseError:
do_more_stuff_in_db()
As explained in the documentation, this pattern has the advantage of delimiting
clearly what gets rolled back when an exception happens, even if the code is
extended or refactored. It's explicit and I like it.
Of course the downside is that you'll have to go through all places where you
catch DatabaseError or a subclass and edit them as above. It sounds doable,
and a good tradeoff for eliminating the risk of nesting commit_on_succes
accidentally or otherwise getting burnt by the old transaction management.
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
