Django Patterns: Model Inheritance

This post discusses the two flavors of model inheritance supported by Django,
some of their use-cases as well as some potential gotchas.

Overview

When the queryset refactor landed a couple years ago, Django’s ORM grew support for model inheritance. Model inheritance comes in two flavors, abstract and … not. What are the important differences in how Django handles these two types of inheritance?

Multi-table inheritance (not abstract)

Directly extending a model results in two tables where the shared fields are
stored in one table (the parent model’s table) and the fields unique to the
child model are stored on the child model’s table. The child model contains a foreign key to the parent model and whenever queried automatically includes the joins.

class Media(models.Model):
    title = models.CharField(max_length=255)
    pub_date = models.DateTimeField()

class Photo(Media): # note that Photo extends Media
    image = models.ImageField(upload_to='photos')

class Video(Media):
    video = models.FileField(upload_to='videos')

class VideoWithThumbnail(Video, Photo):
    """
    Querying this object will result in 3 inner joins on filters/gets

    Saving/deleting will require at least 4 queries, but in my testing
    saving actually required 10 queries and deleting 13!
    """
    pass

Because of the way these items are stored in the database, it is possible to
query against all media objects, whether they’re photos, videos, or just
plain-old Media objects. Querying Media, the base class, will return Media instances without either the special photo or video fields:

>>> Media.objects.all() # get all the media objects, photos or videos
[<Media: Media object>, <Media: Media object>]

>>> Photo.objects.all() # just the photos
[<Photo: Photo object>]

>>> Video.objects.all() # just the videos
[<Video: Video object>]

I find multi-table inheritance useful in the following circumstances:

  • Query against all objects of a type, i.e. all media
  • Relate (via a ForeignKey/M2M) to all objects of a type

I see two main downsides to this type of inheritance:

  • More queries: every insert/update/delete must cascade to all the tables
    in the inheritance chain
  • More joins: every select must against join against all tables
    in the inheritance chain.

There are a couple other things to watch out for:

  • Since the parent model and all the descendants have unique content types,
    Generic ForeignKeys can be a bit cumbersome.
  • Django’s model signals do not cascade to child models, so a post_save handler registered sender=Media would not be called when a Photo object gets saved.
  • You can’t override fields defined on subclasses (true for mixins as well). This makes sense if you think about how this data is being stored.

If you’re interested, there’s a neat project called django_polymorphic
that optimizes this type of inheritance and lets you query the base class and always
returns the “most specific subclass” transparently.

The rest of this post will deal with Abstract models.

Abstract Models, or “Mixins”

OK, multi-table inheritance is admittedly a pretty complicated affair and there a quite a few things to watch out for. Defining a model as abstract and using it as a mixin I find much more intuitive, especially at the database level.

class AbstractMedia(models.Model):
    title = models.CharField(max_length=255)

    class Meta:
        abstract = True # <--- denotes our model as abstract

class Photo(AbstractMedia):
    image = models.ImageField(upload_to='photos')

Basically, an abstract model doesn’t get a table. This has several implications:

  • Subclasses contain all the fields on their table (no joining/parent-fk)
  • Abstract model can’t be queried against
  • Abstract model cannot have a ForeignKey or M2M to it

As Eric Florenzano pointed out in his talk
“Why Django Sucks and How We Can Fix It”,
abstract models introduce a whole new set of problems:

  • trading implementation for configuration – this is probably more in reference to the idea that abstract models provide an elegant solution to the “reuable app problem”
  • extra level of indirection
  • what fields does my model have, and what base class provided them?

That being said, there are definitely valid use-cases for abstract models.
Commonly you’ll hear abstract models referred to as “mixins” and this pretty
well describes what I see as their main strength. They allow bits
of functionality to be wrapped up in a class and reused in many models without forcing you to incur the extra database overhead.

I read in Head First: Design Patterns to “favor composition over inheritance”, which I take to mean that it’s better to build your objects out of smaller pieces than extending/overriding and creating a tall class hierarchy.

Looking at some examples

Mixins can do just about everything that normal models can do, so you can use
them to encapsulate bits of common model functionality. One thing I find myself
doing a lot is auto-generating a slug for my models that have title fields.
This can be wrapped up neatly using a mixin:

from django.db import models, IntegrityError, transaction
from django.template.defaultfilters import slugify

class TitleSlugModel(models.Model):
    title = models.CharField(max_length=255)
    slug = models.SlugField(unique=True)

    class Meta:
        abstract = True

    def save(self, *args, **kwargs):
        """
        Based on the Tag save() method in django-taggit, this method simply
        stores a slugified version of the title, ensuring that the unique
        constraint is observed
        """
        self.slug = slug = slugify(self.title)
        i = 0
        while True:
            try:
                savepoint = transaction.savepoint()
                res = super(TitleSlugModel, self).save(*args, **kwargs)
                transaction.savepoint_commit(savepoint)
                return res
            except IntegrityError:
                transaction.savepoint_rollback(savepoint)
                i += 1
                self.slug = '%s_%d' % (slug, i)


class ContentObject(TitleSlugModel):
    content = models.TextField()

Another common thing I find myself doing is storing a pub/created/modified date.
In this example the ContentObject model will be composed of two abstract models,
the TitleSlug model and the new DateAwareModel. Note that both of the ABCs
are overriding the save() method, but that, because of python’s method resolution
order, everything gets called as we would expect.

import datetime
from django.db import models, IntegrityError, transaction
from django.template.defaultfilters import slugify

class TitleSlugModel(models.Model):
    # everything the same as above

    def save(self, *args, **kwargs):
        print 'title slug model save() called'

        # ... same as above except adding a "print" statement at the top
        # of the method


class DateAwareModel(models.Model):
    pub_date = models.DateTimeField()
    modified_date = models.DateTimeField()
    created_date = models.DateTimeField()

    class Meta:
        abstract = True

    def save(self, *args, **kwargs):
        print 'date aware model save() called'

        if not self.pk:
            self.created_date = datetime.datetime.now()
        self.modified_date = datetime.datetime.now()

        return super(DateAwareModel, self).save(*args, **kwargs)


class ContentObject(TitleSlugModel, DateAwareModel):
    content = models.TextField()

    def save(self, *args, **kwargs):
        print 'content model save() called'
        super(ContentObject, self).save(*args, **kwargs)

Here’s some sample output from the shell showing that all 3 save() methods are
called and our model gets a slug and a modified date.

>>> import datetime
>>> from media.models import *
>>> content_obj = ContentObject(title='testing')
>>> content_obj.pub_date = datetime.datetime(2010, 10, 9)
>>> content_obj.save()
content model save() called
title slug model save() called
date aware model save() called

>>> content_obj.modified_date
datetime.datetime(2010, 10, 9, 13, 31, 57, 782511)

>>> content_obj.slug
u'testing'

Conclusion

Thanks for reading, I hope you found this post informative! Both multi-table
inheritance and abstract models have their place in the django
developer’s toolkit. There’s potential for some serious overhead when using
multi-table inheritance, but you gain the ability to query against all objects
of a base type. Abstract base classes avoid the database overhead by not
creating explicit links in the database, but you lose the ability to query across
subclasses. As always, any comments, feedback, suggestions, errata, etc are
appreciated.

Links

Original Source

Leave a comment