Defered constraint checks flush after `post_delete` signal

[Alex Madjar]

Repro steps:

1. Use a database that supports can_defer_constraint_checks (tested on postgres)
2. Have a model (A) with a null=True ForeignKey or OneToOneField (F) to another model (B)
3. Connect a function to listen to post_delete on (B) that pulls objects of type (A) from the db (using a = A.objects.get... etc )
4. Try to access a.F for an object a that used to be associated with the deleted instance of B that was just deleted

Expectation: a.F_id is None

Actually: a.F_id is the id of the deleted instance and a.F raises an ObjectDoesNotExist exception

Note: doesn't repro on fields where null=False or on sqlite. My diagnosis is that A's field isn't being properly cleared (or A objects deleted in the case of on delete CASCADE) because the constraint checks aren't being flushed until _after_ the post_delete signal fires

[Alex Madjar]

Only tried on CASCADE deletes, I think it blames to this code - ​https://github.com/django/django/blob/master/django/db/models/deletion.py#L15

[Tim Graham]

If you could provide a test case for Django's test suite, that would be helpful.

[Tim Graham]

sample app to reproduce

[Tim Graham]

Seems legitimate. I attached a sample project I used to reproduce. The first test method shows the failure.

[Can Sarıgöl]

​PR