Custom Models

[antho...@gmail.com]

I am relatively new to Django and am hoping somebody can help me. I apologise in advance if this is a very simple question.

I have a model that has an expiry date. In my view I have the following:
queryset = Post.objects.filter(expiry_date__gt=datetime.now()).order_by('expiry_date')

This works in my ListView.

I have been advised that I should put this in a custom model manager and herein lies that the problem. I do not quite understanding how this would work. I understand how to create a custom model manager but not the realtionship with the view.

Could someone please explian this to me?

Many thanks.

[Ryan Castner]

Well first off, while it might be a best practice to make a manager for this, you in no way have to. You can build your website and have it run swimmingly well without doing this abstraction. The whole idea of a Manager is a class that provides some methods to access a model.

Look at the following code:

return super(PublishableManager, self).get_queryset().filter(~models.Q(publish_date=None)).filter(publish_date__lte=timezone.now())

class ExpirationManager(models.Manager):
   
    def not_expired(self):
       return super(ExpirationManager, self).get_queryset().filter(expiry_date__gt=datetime.now()).order_by('expiry_date')

class Post(models.Model):
...
   managed = ExpirationManager()
...


# in your views now

not_expired_posts = Post.managed.not_expired()

So what you have done is created a manager class that is assigned to the `managed` variable of the Post class. Now you have moved the business logic of what a 'not_expired' post is out of your view. 

The advantages here are readability in your views and reusability. Let's say you had other objects with an `expiry_date` field and you want to get objects that weren't expired. Rather than repeat yourself, which violates DRY (Don't Repeat Yourself) you can have the code and logic for non-expired posts in your `Manager` class and whenever a model has a need to manage an `expiry_date` field you can assign the `ExpirationManager` to it. Furthermore you can expand your ExpirationManager to have multiple methods, like `def expired`, `def expired_before`, `def expires_after`, and you write it once and get easy access to all of that functionality wherever you need to use it.

This being said, if you only have an expiration on that one view and you dont need to manage any other kind of queries on the expiry_date field, you definitely dont need to do this, and if you do have need for them you can certainly go on your merry way repeating yourself. Eventually you will look back and say, `man I have written this same query 10 times, there has to be a better way!` and when you get to that point, well, there is!