On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > in my mental model, there are three types of inheritance: > > concrete: two tables, deletion should fire two signals, one for the > child record and one for the parent record. > > abstract: there's no parent table, deletion should fire one signal, > for the child record; unless the parent overrides the delete() method > and chooses to send a custom signal > > proxy: there's no child table. kind of an 'abstract child', instead > of 'abstract parent'. deletion should fire one signal, for the > _parent_ record (which is the only real record), unless the child > overrides the delete() method and chooses to send a custom signal. > > > IOW, i think the existing signals are database-related and should be > fired only for the concrete part(s). if the abstract part wants to, > it can send custom signals.
I agree that signals should not be fired for abstract models. Proxy models are a rather different case, though - they exist precisely in order to be able to augment/supplement Python-level model behavior, and signals are a part of that behavior. It would seem unfortunate to me if you couldn't attach signal handlers specifically to a proxy subclass of a model. Also, firing signals only for the concrete superclass of a proxy model would be a much worse backwards-incompatible change than any of the others discussed. Signal handlers (for delete, save, or init) registered for a proxy model class specifically currently work - with this change they would just suddenly stop firing. > second idea: > > define three different signals: one for concrete members, one for > abstract, and one for both. > > - non-inheritance deletion: > - send concrete-deleted and common-deleted > > - concrete inheritance deletion (both are concrete): > - child: concrete-deleted and common-deleted > - parent: concrete-deleted and common-deleted > > - abstract inheritance (parent is abstract): > - child: concrete-deleted and common-deleted > - parent: abstract-deleted and common-deleted > > - proxy inheritance (child is abstract): > - child: abstract-deleted and common-deleted > - parent: concrete-deleted and common-deleted > > but i think that's overkill Yes, I think this is too much complexity compared to the other solutions. Carl
signature.asc
Description: OpenPGP digital signature
