magic-removal: Model Inheritance

This is a proposal for how subclassing should work in Django. There a lot of details to get right, so this proposal should be very specific and detailed. Most of the ideas here come from the thread linked below:

2. Modeling joins in SQL

When we want a list of ItalianRestaurants, we obviously need all the fields from myapp_restaurant and myapp_place as well. This could be accomplished by inner joins. It would look something like this:

SELECT...FROM myapp_italianrestaurant as ir
INNERJOIN myapp_restaurant as r
ON ir.restaurant_id=r.id
INNERJOIN myapp_place as p
ON r.place_id=p.id

But what if we want a list of Places, what should we do? We can either just get the places:

SELECT...FROM myapp_place

Or we can get everything with left joins (this allows the iterator to return objects of the appropriate type, rather than just a bunch of
Places):

SELECT...FROM myapp_place as p
LEFTJOIN myapp_restaurant as r
ON r.place_id=p.id
LEFTJOIN myapp_italianrestaurant as ir
ON ir.restaurant_id=r.id

Imagine we have more than one subclass of Place though. The join clause and the column list would get pretty hefty. This could obviously get unmanageable pretty quickly.

I think some dbs have a maximum number of joins (something like 16), and even within the maximum, the query optimizer will either spend a while deciding which way to best join the tables or it will give up and choose the wrong way quickly. This wording is FUD-- I'll try to find specifics. --jdunck

Another option is to lazily load objects like Restaurant and ItalianRestaurant while we're iterating over Place.objects.all(), but that requires a lot of database queries. Either way, doing this will be expensive, and api should reflect that. You're much better off just using Places fields if you are going to iterate over Place.objects.all()

Ramblings on Magic Removal Subclassing

If Restaurant were to inherit from this, it would not automatically have a 'name' CharField. This is because Django uses a metaclass to modify the default class creation behavior. The ModelBase metaclass creates a new class from scratch, and then selectively pulls items from the Place class as defined above and adds them to this new class, which allows it to handle Field objects specially. For each of the class's attributes, add_to_class() is called. If add_to_class finds a 'contribute_to_class' attribute, ModelBase knows it is dealing with a Field object, and calls contribute_to_class. Otherwise, it just adds it to the new class via setattr().
Thus, by the time the Restaurant class is created, the Place class which it inherits from actually looks more like this:

Thus, there is simply no 'name' field for it to inherit. So, we need to have ModelBase to walk through the parent classes and call contribute_to_class on each of the fields found in _meta.fields. As we walk the inheritance tree, we look for a '_meta' attribute to determine if our current node is a Model. Otherwise, it is either a mixin class or the Model class iteself.