DatabaseWrapper.needs_rollback and transaction.rollback()

[mark...@gmail.com]

After a validationError occurs, why is the transaction considered dirty, blocking all db reads/writes? In this example: https://bitbucket.org/marky1991/django-test/raw/59c9ff89e4b12b4a831c36171139cb022735201b/test1.py , I don't really expect a TransactionManagementError at all, as the failure in question is a django model ValidationError, so no rollback should be needed, since the save never actually hits the db. At the minimum, however, I would expect a transaction.rollback() to resolve the issue, but it does not.

The traceback: https://dpaste.de/ooTy

Is there a django bug here or are my expectations not correct?

Thanks

[mark...@gmail.com]

I have found this: https://code.djangoproject.com/ticket/26340 , where Aymeric Augustin said that he thought that transaction.rollback should indeed set DatabaseWrapper.needs_rollback to False, as I would expect.

[Simon Charette]

Hello Mark,

Is there a reason for not using the transaction.atomic context manager instead
of managing your transaction manually by calling .set_autocommit(False) and
rollback?

Simon

[mark...@gmail.com]

In the real code, we have much more complex code flow where transaction.atomic offers no readability improvement (imo) over commit_manually. (and even if transaction.atomic were an improvement at all call sites, we have lots of code using commit manually which cannot be changed immediately.)

[mark...@gmail.com]

By "commit_manually" I meant set_autocommit(False). Sorry for the confusion.