On Thu, 2008-04-17 at 14:53 -0700, Justin Fagnani wrote:
[...]
> The first thing is that there seems to be no way to tell if an
> instance of a parent class has a child instance without trying the
> child reference and catching the DoesNotExist exception. For a class
> with multiple subclasses, this is a cumbersome, so I've been adding a
> _type field to parent classes that gets set in save() of the
> subclasses.
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.
> Is there a better way to do this, or is this something that could be
> included? I know there's no way to determine whether or not a class
> will be subclassed in the future, so I wouldn't be surprised if the
> answer is no.
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.
> But maybe there should be a documented pattern.
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.
> The odd part is what happens with the child reference. parent.child
> obviously works as expected, and returns either an instance of Child
> or raises DoesNotExist. But for an instance of Child, .child always
> returns a reference to itself, so that c.child == c is always True.
> This makes sense on one hand, because c is also an instance of Parent,
> but on the other, Child doesn't have a subclass, so should .child be
> None?
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.
> I haven't actually encountered this in any real life situation,
> because it's hard to end up with collection in Django where you have a
> mix of parent and child instances, so maybe it'll never be a problem.
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).
> One additional thing is that in one case, I know which subclasses I'm
> interested in, and it'd be great to have a way to specify that a
> queryset should return polymorphic results by specifying the
> subclasses for the join. Something like:
>
>
> Parent.objects.all().select_subclasses('Child1','Child2')
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/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
