I recently upgrade Django 1.7->1.8 and ended up needing to patch set_rollback() and comment out the "exception if not in an atomic block" part. The problem was that sometimes database errors like IntegrityError occurred because multiple workers was trying to create the same data but that's ok, the code captures the error and does a get instead of a create and moves on. A rollback was not an option here as that wound roll back a lot of other things that was ok. Way do you need to be in a atomic block to use this function? Is the filosofi of Djangos transaction handling that an exception from the database should always be handled with a rollback no matter what?
Cheers Tore -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a8daaa98-f66a-40e5-bb4d-c0d4ad647f70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
