Changes between Version 2 and Version 3 of ModelInheritance


Ignore:
Timestamp:
01/26/06 12:23:50 (9 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}}}
Back to Top