#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-------------------------------------+-------------------------------------
Reporter: svetlyak40wt | Owner: jdunck
Type: New feature | Status: assigned
Component: Core (Other) | Version: 1.0
Severity: Normal | Resolution:
Keywords: model inheritance, | Triage Stage: Accepted
signals, dispatch, proxy, | Needs documentation: 0
subclass | Patch needs improvement: 1
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by carljm):
Replying to [comment:20 carljm]:
> I'll also repeat one comment I made on #18094: I think a fix that relies
on opt-in from the person registering the signal handler is not adequate,
as this is often not the same person who might be creating a subclass
(particularly a proxy subclass). A reusable app that registers a signal
handler for a model ought to be able to assume that that handler will fire
when instances of that model are involved, without needing to take special
opt-in steps to ensure that this is still the case when subclasses are
involved.
Although I suppose that this might be a necessary concession to backwards
compatibility - in that case, it should be featured in the documentation,
as I would think that most new code should register signal handlers using
this new opt-in flag (and perhaps we should even consider deprecating the
flag over time in favor of making this the default behavior).
--
Ticket URL: <https://code.djangoproject.com/ticket/9318#comment:21>
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.
