Joseph Kocherhans wrote: > Is this a good summary of the current thinking on subclassing? > > http://groups.google.com/group/django-developers/browse_frm/thread/ea5e0bf903058fac/9a68ac0d99cb6d7d?q=semantics&rnum=1#9a68ac0d99cb6d7d > > The wiki doesn't say a whole lot about it, although it's probably in > someone's brain ;) > > Joseph >
Just a few vague notes about how I planned to implement this: I wanted to possibly in future support different inheritance models. The other sane ones (AFAIK) are: * Concrete table model (only works with databases with sequences). A table is made with all attributes for each concrete class. Base class queries are done with unions rather than joins. All the concrete tables in one inheritance hierarchy share a sequence for id generation so that no two instances of the supertype share an id. * Inheritance-hierarchy in one table. Every attribute gets stuck into one table. One column is given over to the type of each row. Attributes are null for all rows that they are not valid for. Extra check constraints generated for attributes that are not logically null. Good for the join-shy. So the idea was to have a class InheritanceModel, that eg the manager and the sql creation stuff would refer to. There would be a default implementation using one-to-one relationships. This could be overridden in class Meta. So signals can be used to control this. A signal should be emitted by the metaclass for each base class that is a subclass of Model. The inheritance model should listen for these signals and build up the inheritance tree. I think it is worth seperating out the inheritance policy so different database mappings can be tried out in future. Anyway, Good luck, Rob
