Skip to main content

Django Models Mixins

One thing I've been experimenting with is model Mixins.  For example, the aim is to create small abstract classes that are each focused around a particular function.  These abstract classes can then be added to arbitrary models to apply those functions to models as desired.

For example, say I define a RatingsFields abstract class and a TrackingFields abstract class.  These abstract classes can be mixed into any other model that we wish to add rating or tracking functionality to.

core/mixins.py
from djangoratings.fields import RatingField # 3rd party module

class RatingFields(models.Model):
    
    rating = RatingField(range=5) # 5 possible rating values, 1-5

    class Meta:
        abstract = True
        

class TrackingFields(models.Model):

    deleted_on = models.DateTimeField(blank=True, null=True)
    created = models.DateTimeField(auto_now_add=True)
    modified = models.DateTimeField(auto_now=True)

    class Meta:
        abstract = True
        

Since we applied the abstract classes to the Post model below, the model now has rating and tracking capabilities.  This is useful to help simplify code where a lot of models share fields or methods with the same function.

myapp/models.py
from core import mixins as core_mixins
class Post(core_mixins.TrackingFields, core_mixins.RatingFields):
    name = models.CharField(max_length=128)
    slug = models.SlugField(max_length=128)
    ...

Comments welcome.
Joe

Comments

  1. Did you try django.contrib.contenttypes?

    ReplyDelete
  2. Thanks for your comment, Pavel. I've used content types and generic relations in the past and they are very useful.

    With this mixin approach, the fields are created on the given table rather than linked through a foreign key. This might be handy for situations where we know we are going to need the same fields on a given table - such as the TrackingFields - and want to avoid code duplication. Granted, this might reduce some of the flexibility that a generic relation would afford us, but perhaps also reduce some of the complexity.

    If you have other thoughts or suggestions regarding this, please feel free to share. I'm eager to learn of better approaches. Thank you again,
    Joe

    ReplyDelete
  3. Thanks Eduardo... core_interfaces is a copy-paste error. I've made the correction. Thank you for pointing that out.

    ReplyDelete
  4. Although this is a good example of using mixins, I wouldn't call this an example of aspect-orientated programming.

    ReplyDelete
  5. Thanks cody-somerville. Perhaps I was off on my naming. I'll adjust the title name.

    ReplyDelete
  6. I was trying to figure out the best way to do this (see http://stackoverflow.com/questions/6428075/is-it-ok-to-use-multiple-inheritance-with-django-abstract-models) , whether my Mixins needed to inherit from models.Model or not, and so forth. This is a good anwser.

    ReplyDelete
  7. Name and slug are very generic too, you could put them in a mixin...

    ReplyDelete

Post a Comment

Popular posts from this blog

Django Docker and Celery

I've finally had the time to create a Django+Celery project that can be completely run using Docker and Docker Compose. I'd like to share some of the steps that helped me achieve this. I've created an example project that I've used to demo this process. The example project can be viewed here on Github.

https://github.com/JoeJasinski/docker-django-demo/tree/blogpost

To run this example, you will need to have a recent version of Docker and Docker Compose installed. I'm using Docker 17.03.1 and Docker Compose 1.11.2.

Let's take a look at one of the core files, the docker-compose.yml.   You'll notice that I have defined the following services:
db - the service running the Postgres database container, needed for the Django apprabbitmq - service running the RabbitMQ container, needed for queuing jobs submitted by Celeryapp - the service containing Django app containerworker - the service that runs the Celery worker containerweb - the service that runs the Nginx con…

Django Admin Override Save for Model

Sometimes it's nice to be able to add custom code to the save method of objects in the Django Admin.  So, when editing an object on the Admin object detail page (change form), adding the following method override to your ModelAdmin in admin.py will allow you to add custom code to the save function.

In admin.py:  
class MyModelAdmin(admin.ModelAdmin): def save_model(self, request, obj, form, change): # custom stuff here obj.save()
This is documented in the Django Docs, but I found it particularly useful.

Django: Using Caching to Track Online Users

Recently I wanted a simple solution to track whether a user is online on a given Django site.  The definition of "online" on a site is kind of ambiguous, so I'll define that a user is considered to be online if they have made any request to the site in the last five minutes.

I found that one approach is to use Django's caching framework to track when a user last accessed the site.  For example, upon each request, I can have a middleware set the current time as a cache value associated with a given user.  This allows us to store some basic information about logged-in user's online state without having to hit the database on each request and easily retrieve it by accessing the cache.

My approach below.  Comments welcome.

In settings.py:
# add the middleware that you are about to create to settings MIDDLEWARE_CLASSES = ( .... 'middleware.activeuser_middleware.ActiveUserMiddleware', .... ) # Setup caching per Django docs. In actuality, you'd p…