On Thu, Apr 12, 2012 at 11:31 AM, Carl Meyer <[email protected]> wrote:
> Thoughts?
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.
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
--
Javier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
