Custom Model Managers
Why Use a Custom Manager?
A custom manager lets you package a common filter, like 'only published tutorials', into a reusable method instead of repeating filter() everywhere.
Example: Why Use a Custom Manager?
This manager's get_queryset() always starts from only published rows, before any further filtering is applied.
from django.db import models
class PublishedManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(is_published=True)
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
Attaching a Manager to a Model
You attach a custom manager by assigning it to a class attribute on the model, just like a field.
Note: Adding a second manager doesn't remove the default objects manager unless you leave it out entirely.
Example: Attaching a Manager to a Model
Tutorial.objects.all() still returns everything, while Tutorial.published.all() returns only published tutorials.
class Tutorial(models.Model):
title = models.CharField(max_length=200)
is_published = models.BooleanField(default=False)
objects = models.Manager()
published = PublishedManager()
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
Using the Custom Manager
Once attached, the custom manager is used exactly like the default objects manager, just with a different name.
Example: Using the Custom Manager
Both calls automatically start from only published tutorials, since that filter lives inside the manager itself.
from core.models import Tutorial
Tutorial.published.all()
Tutorial.published.filter(category='Forms')
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
- Overriding the default objects manager entirely without adding it back, which breaks Django admin and other code that expects Model.objects to exist.
- Putting query logic inside the model's methods instead of a Manager, making it unusable directly from the model class.
- Forgetting to call super().get_queryset() inside a custom get_queryset() override, losing the base queryset behavior.
- A custom Manager is a class that subclasses models.Manager and defines extra query methods.
- Attach it to a model as a class attribute, commonly named objects or something more specific.
- Override get_queryset() to change what the base queryset returns for every query through that manager.
Chapter Quiz — Complete all 9 topics to unlock
0/9 topics done
Complete these topics first: