On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote: > Rather than watch the "inherit from User" thread go round and round, > maybe I should give people something more concrete to think about.
W00t -- I'm about +1,000 on your proposal; it's well-thought-out, clean, and seems to hit all the right notes. I've got a few questions, obviously, but nothing major. You've certainly got *my* blessing to go forward with this. > (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? > (2) Any strong reason not to include this case? It's only for > "advanced > use", since there are a few ways to shoot yourself in the foot (e.g. > declare a class abstract, create the tables, remove the abstract > declaration, watch code explode). However, it will be useful in some > cases. [I have some scripts to help with converting non-abstract > inheritance to abstract and vice-versa at the database level, too.] I think abstract base classes are *key*, actually -- nearly every use I'm thinking of includes 'em. > 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. > (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. As long as I get to choose what that extra column is called... oh, reading below shows that you've already addressed that; cool. Awesome. I'm looking forward to seeing the code! Jacob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
