Code

Changes between Version 2 and Version 3 of ModelInheritance


Ignore:
Timestamp:
01/26/06 10:23:50 (8 years ago)
Author:
jkocherhans
Comment:

initial draft of subtyping proposal... still *really* rough

Legend:

Unmodified
Added
Removed
Modified
  • ModelInheritance

    v2 v3  
    22 
    33http://www.djangoproject.com/documentation/models/subclassing/ 
     4 
     5 
     6= magic-removal: Model Inheritance = 
     7 
     8This 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: 
     9 
     10http://groups.google.com/group/django-developers/browse_frm/thread/ea5e0bf903058fac/9a68ac0d99cb6d7d?q=semantics&rnum=1#9a68ac0d99cb6d7d 
     11 
     12== Subclassing == 
     13 
     14For subclassing, there are 3 main issues: 
     15 
     16 1. How do we model the relations in SQL? 
     17 2. How do joins work? 
     18 3. How does the API work? 
     19 
     20Note that I have only provided examples for single inheritance here. Is multiple inheritance worth supporting? 
     21 
     22The examples will use the following models: 
     23{{{ 
     24#!python 
     25class Place(models.Model): 
     26    name = models.CharField(maxlength=50) 
     27 
     28class Restaurant(Place): 
     29    description = models.TextField() 
     30 
     31class ItalianRestaurant(Restaurant): 
     32    has_decent_gnocci = models.BooleanField() 
     33}}} 
     34 
     35 
     36=== 1. Modeling parent relations in SQL? === 
     37 
     38  1. Foreign key to parent table named $(parenttable)_id 
     39  2. Foreign key to parent table named 'parent_id' 
     40  3. 'id' of parent row equals 'id' of child row 
     41 
     421. and 2. would take up part of the objects namespace. With 1, you couldn't have attributes named $(parenttable)_id or 'parent_id' respectively. 
     43 
     44With option 3, auto-incrementing might be harder, but it makes more sense to have 1 id across the board. I think one would expect {{{Place.objects.get(2)}}} to return the "same" object as {{{Restaurant.objects.get(2)}}}. 
     45 
     46Here's an example of option 1: 
     47{{{ 
     48#!sql 
     49CREATE TABLE "myapp_place" ( 
     50    "id" integer NOT NULL PRIMARY KEY, 
     51    "name" varchar(50) NOT NULL 
     52); 
     53 
     54CREATE TABLE "myapp_restaurant" ( 
     55    "id" integer NOT NULL PRIMARY KEY, 
     56    "place_id" integer NOT NULL REFERENCES "myapp_place" ("id"), 
     57    "description" text NOT NULL 
     58); 
     59 
     60CREATE TABLE "myapp_italianrestaurant" ( 
     61    "id" integer NOT NULL PRIMARY KEY, 
     62    "restaurant_id" integer NOT NULL REFERENCES "myapp_restaurant" ("id"), 
     63    "has_decent_gnocci" bool NOT NULL 
     64); 
     65}}} 
     66 
     67and option 3: 
     68{{{ 
     69#!sql 
     70CREATE TABLE "myapp_place" ( 
     71    "id" integer NOT NULL PRIMARY KEY, 
     72    "name" varchar(50) NOT NULL 
     73); 
     74 
     75CREATE TABLE "myapp_restaurant" ( 
     76    "id" integer NOT NULL PRIMARY KEY, /* Could this reference myapp_place's id too? Doubtful. :( */ 
     77    "description" text NOT NULL 
     78); 
     79 
     80CREATE TABLE "myapp_italianrestaurant" ( 
     81    "id" integer NOT NULL PRIMARY KEY, /* Ditto for referencing myapp_restaurant's id */ 
     82    "has_decent_gnocci" bool NOT NULL 
     83); 
     84}}} 
     85 
     86=== 2. Modeling joins in SQL === 
     87 
     88When we want a list of {{{ItalianRestaurant}}}s, we obviously need all the fields from myapp_restaurant and myapp_place as well. This could be accomplished by left joins. It would look something like this: 
     89{{{ 
     90#!sql 
     91SELECT ... 
     92FROM myapp_italianrestaurant as ir 
     93LEFT JOIN myapp_restaurant as r 
     94ON ir.restaurant_id=r.id 
     95LEFT JOIN myapp_place as p 
     96ON r.place_id=p.id 
     97}}} 
     98 
     99 
     100But what if we want a list of {{{Place}}}s, what should we do? We can either ''just'' get the places: 
     101{{{ 
     102#!sql 
     103SELECT ... 
     104FROM myapp_place 
     105}}} 
     106 
     107Or we can get ''everything'' with left joins (this allows the iterator to return objects of the appropriate type, rather than just a bunch of  
     108{{{Places}}}): 
     109{{{ 
     110#!sql 
     111SELECT ... 
     112FROM myapp_place as p 
     113LEFT JOIN myapp_restaurant as r 
     114ON r.place_id=p.id 
     115LEFT JOIN myapp_italianrestaurant as ir 
     116ON ir.restaurant_id=r.id 
     117}}} 
     118 
     119Imagine 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. 
     120 
     121Another 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 {{{Place}}}s fields if you are going to iterate over {{{Place.objects.all()}}} 
     122 
     123 
     124=== 3. API === 
     125 
     126The following API examples assume we have created these objects: 
     127 
     128{{{ 
     129#!python 
     130p = Place(name='My House') 
     131r = Restaurant(name='Road Kill Cafe', description='Yuck!') 
     132ir = ItalianRestaurant(name='Luigis', description='Something', has_decent_gnocci=False) 
     133}}} 
     134 
     135For the following examples, assume {{{Place.objects.get(2)}}} returns {{{r}}} and  
     136{{{Place.objects.get(3)}}} returns {{{ir}}}. 
     137 
     138||    || python                                    || result || 
     139|| A. || {{{Place.objects.count()}}}               || 3 || 
     140|| B. || {{{Restaurant.objects.count()}}}          || 2   || 
     141|| C. || {{{ItalianRestaurant.objects.count()}}}   || 1   || 
     142|| D. || {{{Place.objects.get(2).description}}}    || 'Yuck!' or {{{AttributeError}}}? || 
     143|| E. || {{{Restaurant.objects.get(2).description}}}    || 'Yuck!' || 
     144 
     145 
     146 
     147== Change the current usage of subclassing == 
     148 
     149{{{ 
     150#!python 
     151class MyArticle(Article): 
     152  ...fields... 
     153  class META: 
     154        module_name = 'my_articles' 
     155        remove_fields = ...some fields... 
     156}}} 
     157 
     158would change to: 
     159{{{ 
     160#!python 
     161 
     162class MyArticle(meta.Model): 
     163   ...fields... 
     164   class META: 
     165        copy_from = Article 
     166        remove_fields = ...some fields... 
     167}}}