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?
> Points To Ponder
> ================
> (1) What notation to use to declare a class as abstract? I've thrown out
> Meta.is_abstract -- any preference for alternatives?
A marker interface: models.AbstractModel. That gives you a place to put
support functionality if you need it later (like polymorphic
association). It indicates the class is fundamentally different (which
I think it is). I suspect people are less likely to mess around with
inheritance chains than field settings on the Meta class.
> 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.
> -----------------------
> 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?
cheers
Bill
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
