[...]

That's a reasonable way to do it.

Another way is to have an extra table that maps object id and content
type to "most derived content type" or something. If you had third-party
models you were subclassing, that isn't too hard to implement either.

That's right. There's no way to tell if something's going to be
subclassed and we don't want to change any third-party database tables
(a design feature is that you *must* be able to subclass third-party
models transparently). Also, it's quite fiddly to keep such fields up to
date if you think about the manipulation required for A subclassed by B
subclassed by C. You end up with type fields everywhere.

I'll add something. It seems kind of obvious, though, and given that it
isn't a particularly common pattern to query the parents and descend to
the children (if you care about the differences, you'll usually be
querying the children directly; if you care about the common stuff, it's
all on the parent), I'd kind of hope people needing this already had the
skills to connect A to B.

A couple of sentences won't confuse things too much, though. We can fix
that.

Hmm, hadn't noticed that, although it's not too surprising. My first
reaction is "well, don't do that."

It's quite possibly fiddly to fix, since reverse relations (which is
what the "child" attribute is) should be transparently accessible on any
child class even when they exist on the parent. I think I tried to
prevent the "traversing down to yourself" case at one point and it trips
up when you have multiple subclasses. The structure in the
tests/model_inheritance/models.py test file is a bit of a medium-level
stress test for this behaviour, since multiple unrelated things inherit
from Place and Restaurant (and are related to them and each other) and
there are more twisted cases out there, too. They're not in the test
because they rapidly become almost opaque to comprehension and we try to
keep the tests reasonably clean.

It's probably overkill to add in lots of extra processing to avoid the
case of "things on the path that lead to myself, but don't stop too soon
in the hierarchy" when it's probably easier just to not access that
attribute in the code.

The hard cases are always multi-layer hierarchies (trees of inheritance,
not just linear or dual-level cases). I'll have another look now that
it's been a while since I last look at it and maybe there's an easy fix,
but try to avoid doing that. It doesn't make sense.

Indeed (hopefully).

We're not actually just making this up as we go along and I suspect
you'll find that the cases that are harder are also relatively rare.
Quite a few of the people involved in the design of this stuff in Django
(particularly 18 months or so ago when we were doing some heavy lifting
in the design are), including myself, have a fair bit of experience with
other OO and inheritance-based systems such as C++, Java, relational
database design and CORBA interfaces,  in addition to Python. Duck
typing is handy quite often in Python, but inheritance at the data layer
level doesn't seem to be one of them. Every situation we could come up
with, or knew about from experience is possible and I hope we've found a
nice middle-ground in order to make the common stuff easy and the rarer
stuff possible (of course, one man's common is another man's rare, but
that's life in a crowded space).

Maybe one day.

It's not significantly less faster to just create two querysets in this
case and then merge the two iterators to get a combined iterator of the
results (if you care about them being ordered properly, merge sort is
your fiend -- otherwise just use itertools.chain).

Combining disparate sets of output columns into the appropriate models
is quite a bit of extra processing and querysets are already not the
fastest things in the world. Adding bells and whistle features like this
that are always on the common processing path -- every time we construct
some results we need to check if special classes have been specified and
act accordingly -- when it's only a few lines of Python to do it in your
own code might not be worth it.

Regards,
Malcolm

--
I just got lost in thought. It was unfamiliar territory.
http://www.pointy-stick.com/blog/