On Sun, 2006-07-23 at 11:31 -0500, Jacob Kaplan-Moss wrote:
> On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote:
[...]
> 
> > (1) What notation to use to declare a class as abstract? I've  
> > thrown out
> > Meta.is_abstract -- any preference for alternatives?
> 
> Bill de hÓra suggests ``models.AbstractModel``... hm...
> 
> I think I agree with him that ``AbstractModel`` looks cleaner -- I  
> like seeing that a model is abstract right there at the top rather  
> than having to read down to ``Meta`` to see what's going on.
> 
> However, what about the case when I want to do something with more  
> than one level of abstract models.  Say I want abstract ``Shape``,  
> ``2DShape``, and ``3DShape`` classes (where 2D and 3D extend  
> ``Shape``)... How would that work with your syntax, Bill?

That's a valid problem.

[...]
> > The traditional Python inheritance model allows one to create  
> > instances
> > of the base class and work with instances of base classes as though  
> > they
> > were the parent. Extending this to Django's querying model, we  
> > should be
> > able to run queries against the Parent class:
> >
> >         Thing.objects.filter(name = "horse")
> >
> > in the above example and, through the magic of duck typing, have the
> > right sort of object returned.
> 
> So I'd get back an iterator that yields Things, Animals, and Toys?  
> That's what I'd expect, and want.

Yep, that's how it would work. At the moment, it's lazy, in that you get
back an object of the right type, but it's lazy and doesn't populate the
sub-class fields until you demonstrate you want them. There's a
reasonable chance you're going to be discriminating further on type
anyway, or just wanting to access the Thing fields.

I would like to have an equivalent of select_related() that allowed you
to populate all the sub-data for a collection of objects, too, I think.
That's not implemented yet, since it's not critical to the functionality
(and there are a couple of API issues because of how I can think I would
use it). So that's off to one side at the moment.

> > (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 think I'd need to see the code to understand what this extra column  
> does, but a "magic" inheritance table seems a little scary to me and  
> I'd be inclined against it.

Obviously seeing the code should clarify, but in the interim...

If I select a row from the Thing table, the object returned should be
the proper type (which isn't necessarily a Thing -- it could be Animal
or Toy). So I need to know what the most derived type is for this row in
order to generate the right object. Doing a scan over all possible
sub-classes to find out where the id-linking trail runs out is very
expensive. Caching content-types in memory as we access them (something
that comes up as useful in a number of situations) and doing a deep dive
to the right class immediately using this column's value is the idea.

By the way, this introduces something I didn't mention previously (it's
an implementation point): in order for model inheritance to work in this
sort of set up, it needs content types. Content types are a "contrib"
option at the moment. I'm not sure if that worries me a lot or not. It
keeps rattling around in my head, though.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to