Django 1.8b2: m2m signal raising ProtectedError now affects unrelated queries inside tests

[Peter Schmidt]

I'm trying out Django 1.8b2, and am getting close to getting our main project's test suite passing. However I've run into this behaviour and I'm just curious whether anyone else has experienced it or has any thoughts. 

TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

Code to reproduce with command ./runtests.py m2m_signals

https://github.com/django/django/compare/stable/1.8.x...mathspace:m2m_atomic

The test (with a minor import merge conflict) can be rebased onto the stable/1.7.x branch and passes there.

I think it's related to this documented change:

https://docs.djangoproject.com/en/dev/releases/1.8/#related-object-operations-are-run-in-a-transaction

We can fix it by catching the known instance of ProtectedError explicitly which we probably should be doing in our signal anyway.

But it's not clear if we can always catch ProtectedError for all possible protected relationships, and whether that could be a symptom of something that might affect more downstream code (like possibly different future requests to a Django app server with persistent DB connections... just a hypothesis?). Django's deep ORM internals are well out of my depth so if anyone can shed light on this (e.g. hopefully I'm completely wrong with my hypothesis), that would be appreciated.

[Florian Apolloner]

Hi Peter,

On Thursday, March 12, 2015 at 11:26:21 AM UTC+1, Peter Schmidt wrote:

I think it's related to this documented change:

https://docs.djangoproject.com/en/dev/releases/1.8/#related-object-operations-are-run-in-a-transaction

Exactly
 

We can fix it by catching the known instance of ProtectedError explicitly which we probably should be doing in our signal anyway.

Yes, you should
 

But it's not clear if we can always catch ProtectedError for all possible protected relationships, and whether that could be a symptom of something that might affect more downstream code (like possibly different future requests to a Django app server with persistent DB connections... just a hypothesis?). Django's deep ORM internals are well out of my depth so if anyone can shed light on this (e.g. hopefully I'm completely wrong with my hypothesis), that would be appreciated.

At the end of requests, the transactions are reset anyways, leakage into other requests (persistent connection or not) cannot happen.
 
Cheers,
Florian

[Peter Schmidt]

Thanks Florian.