Hi! I noticed dangerous behaviour with testing and usage of *select_for_update *in transactions. This "feature" crashed some parts of production in our company. The "feature" I am talking about, is that test runner wraps all tests in a transaction. If you use *select_for_update* you have to wrap it in a transaction.atomic(). That is quite obvious as django raises an error if query is not in a transaction. This is what happened at our company:
1. One code block was wrapped in transaction atomic where select_for_update was used. The code was tested in a django test. 2. transaction.atomic context manager was accidentally removed. The test still passed as test runner wraps test in it's own transaction. 3. Code was happily deployed 4. On production server there was no more transaction wrapper and exception was raised at select_for_update 5. ... 6. Hotfix galore Is there any option to separate the transaction wrapper for testing and normal code execution? I am not familiar with internals of test runner etc., but would gladly take a look. What are your opinions about this? - Klemen -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/be5bd163-5915-4890-b225-78094c773eb8n%40googlegroups.com.
