id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 28099 Reuse of UpdateQuery breaks complex delete updates milosu nobody "I've discovered some obscure bug, which triggers randomly and only under certain circumstances, based on the address space layout. Try to apply attached delete_on_update_bug.py and run delete_regress multiple times. The test case should fail with: {{{ ====================================================================== FAIL: test_delete_with_custom_handlers (delete_regress.tests.CollectorUpdateTests) ---------------------------------------------------------------------- Traceback (most recent call last): File ""C:\data\django\tests\delete_regress\tests.py"", line 381, in test_delete_with_custom_handlers self.assertEqual(cost_claim_in_report.threatened_id, t_org_in_report.pk) AssertionError: None != 2 ---------------------------------------------------------------------- Ran 19 tests in 0.970s }}} I can reproduce this bug with latest Django when I make several tweaks, that change the address space layout of the Python process, besides others: - use psycopg2 backend while testing instead of the dummy default - try to put pdb near the random shuffle - add somehow additional DLLs to the Python process etc. The issue can be fixed by applying delete_on_update_fix.diff. The root cause is the reuse of sql.UpdateQuery across the inner for-loop, due to the way update_batch is implemented (by calling add_update_values etc.). Caveats: The print statement in delete_on_update_bug.diff prints the order of the items when iterating over the field_updates dictionary. The order that breaks the test case is one of the following: organization None set([]) threatened None set([]) organization None set([]) i.e. update of ""organization"" fkey on must follow after the update of the ""threatened"" attr. " Bug closed Database layer (models, ORM) 1.11 Normal duplicate Accepted 1 0 0 1 0 0