On Sun, 2006-07-23 at 17:12 +0100, Bill de hÓra wrote:
> Malcolm Tredinnick wrote:
>
> > -----------------------
> > 1. Abstract Base class
> > -----------------------
> > [...]
> >For example,
> >
> > class Thing(models.Model):
> > name = models.CharField(...)
> >
> > class Animal(Thing):
> > genus = models.CharField(...)
> >
> > class Toy(Thing):
> > manufacturer = models.CharField(...)
> >
> > would generate two database tables (Thing does not get its own table).
> > The Animal table would have "name" and "genus" columns (along with the
> > standard extras like "id") and Toy would have "name" and "manufacturer"
> > columns.
>
> I bet people will want to compare and load these things (no pun
> intended) via the DBAPI ("gimme all the Things, I'll sort them out").
> Point being, if you give people superclasses, they'll want to use them.
> Will there be a way to polymorphically associate Animal and Toy with
> Thing behind the scenes so that I work at the highest level of
> abstraction, via the Thing class?
I wasn't planning on it. Well, I was, in that you do it by not marking
Thing as abstract! "Will never instantiate one of these" is a guiding
principle for this abstract concept. Yes, it's non-Pythonic; it's an
accomodation to the database model for optimisation purposes only. Most
of the time, people should just trust that their database was built by
professionals and will be fast enough and just use normal inheritance.
If you want to use abstract classes, then you are committing to further
restrictions.
That being said, it's not something I'm against per se. I just can't see
how it will work easily. We can look at this in due course, though. It's
added functionality, so something we could even put in later if we
wanted to (that is to say, interesting idea, but not my focus right now
unless you can convince me it's a showstopper for some reason beyond
"people can't read the instructions").
[...]
> > Points To Ponder
> > ================
> > (3) I think having the downward reference column (the one that specifies
> > the type of the most-derived object) as a column on each table is the
> > right approach. Anybody have strong arguments for the other approach (a
> > separate table)?
>
> I'm aware that hibernate doesn't use a type discriminator in the
> supertable, on the basis it's more true to relational thinking. I have
> no idea how they made it performant.
Interesting. Maybe it's just universally sucky and one doesn't notice
the extra overhead. :-) Hibernate has a reasonable rep, though. Hmm...
I might have a quick look at what they're doing. Without a
discriminator, it would seem to be impossible to avoid doing O(# of
subclasses, including non-leaf classes) queries each time, which seems
"not cool". Still, thanks for the tip.
> > -----------------------
> > 3. What you don't get
> > -----------------------
> > [...]
> > I am not implementing the "everything in one table" storage model. It is
> > not universally applicable (you can't inherit from third-party models,
> > for a start) and I have software engineering objections to it.
>
> Why? NOT NULL constraints in the children?
That's one good reason. It's also not very normalised; table design with
lots of sparse columns won't get me invited to the cool parties. Wide
rows where you only need to access a few fields tend to not always
perform as well as people might like (I'm talking about very large
datasets here; small datasets don't matter so much).
Finally, because I would like to support extending third-party models
out of the box, we need the multi-table model and I don't want/need the
extra complexity of more and more alternatives right now. That's
something somebody could add later if their continued existence depended
on it. It's all "under the covers" work.
I'm on a "pick one thing, do it well" drive at the moment (with a slight
concession to the abstract base class case).
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
