#26630: Defered constraint checks flush after `post_delete` signal
----------------------------------------------+--------------------
Reporter: alexmadjar | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
Repro steps:
1. Use a database that supports `can_defer_constraint_checks` (tested on
postgres)
1. Have a model (A) with a `null=True` ForeignKey or OneToOneField (F) to
another model (B)
1. 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 )
1. 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
--
Ticket URL: <https://code.djangoproject.com/ticket/26630>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/053.f3c1869f725560891e1948d52aed5d67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
