#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: charettes
Type: Bug | Status: assigned
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: model proxy multi- | Unreviewed
table inheritance signals delete | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by carljm):
Just to toss in my several cents:
* I agree with akaariai that signals for a child proxy should definitely
not be sent when a parent proxy is deleted.
* It initially seemed wrong to me to send a separate signal for each
proxy-equivalent model class, but I was swayed by the argument of internal
consistency with non-proxy (concrete) parents, where a separate signal is
sent for each concrete parent, and that fact that the common idiom for
attaching to model signals doesn't attach to signals sent by "this class
or any subclasses," which means that e.g. deleting a proxy `User` will not
execute signal handlers people have attached to `User` deletion, even
though the `User` is in fact deleted. This seems like a serious problem,
and adding an inherit=True to handler connection doesn't solve it, because
it places the onus on the wrong person; the signal author, not the proxy
`User` author. Somebody with a reusable app that attaches a deletion
handler to `User` ought to be able to presume that it will get called when
a `User` is deleted, and they shouldn't need to explicitly consider the
case of proxy models and add `inherit=True` in order to make that
assumption true.
* I'm not sure about consistency with save. I think the practical back-
compat consequences of firing more signals for the different classes is
probably minimal, since the common pattern is to use `sender=Foo`, which
will still catch only one of the several signals (though it's true that
some auditing schemes might attach to pre_save/post_save indiscriminately
and would then get duplicated data). In any case, I'm more concerned about
getting sensible internal consistency within deletion signals than about
consistent behavior between various ORM methods (though I agree that is
also desirable, if we can make it happen).
--
Ticket URL: <https://code.djangoproject.com/ticket/18094#comment:6>
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
