Re: DatabaseWrapper.needs_rollback and transaction.rollback()

I created an issue for this https://code.djangoproject.com/ticket/27504 , and created a pull request as well: https://github.com/django/django/pull/7577. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

> On 16 Nov 2016, at 16:35, Mark Young wrote: > > Once I know the preferred fix, I'll work on the patch. Unfortunately the hard part is to figure out what the preferred fix is :-/ It's likely to be a trivial one liner. Tests may be a bit more involved. > One thing I still don't understand is w

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

Re fixing transaction.rollback: What would be the preferred way to fix this? I haven't personally tested it (a coworker has and reports that it doesn't work), but BaseDatabaseWrapper.set_rollback requires that in_atomic_block be True when set_rollback is called, which is not the case in this ex

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

Hello Mark, Indeed this is the bug described in https://code.djangoproject.com/ticket/26340 . It hasn’t been fixed yet because things become complicated with savepoints and because it isn’t obvious that it cannot introduce data corruption bugs. Perh

DatabaseWrapper.needs_rollback and transaction.rollback()

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