Custom Managers & QuerySets

A Django Manager is the interface attached to a model as Model.objects that provides database query operations and returns a QuerySet, making it the gateway through which every query begins.

Learn Custom Managers & QuerySets in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Django course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll see what the default objects manager really is, write a custom Manager that adds methods like published() and overrides get_queryset() , and build a chainable custom QuerySet with as_manager() so calls like Post.objects.published().recent() just work.

Every Django model you define automatically gets a Manager attached under the name objects . A manager is the object that provides query operations — it is the gateway to the database. When you write Post.objects.all() or Post.objects.filter(...) , you are calling methods on that manager, and what comes back is a QuerySet representing rows.

The manager itself holds very little state. Its key method is get_queryset() , which builds and returns the base QuerySet that all() , filter() , and friends start from.

To stop repeating filter(status="published") everywhere, you subclass models.Manager and add a method that wraps it. Inside the method you call self.get_queryset() and filter that, so Post.objects.published() reads like plain English.

You can also override get_queryset() itself to change the default set the manager returns. A LiveManager whose get_queryset() excludes drafts means every query through it is already filtered:

A method on a manager can only be called first — Post.objects.published() works, but Post.objects.filter(...).published() does not, because filter() returns a plain QuerySet that has never heard of published() . The fix is to put the methods on a custom QuerySet subclass, where each method returns another QuerySet and therefore chains .

PostQuerySet.as_manager() builds a manager whose methods come from the QuerySet, so the same logic is available straight off objects and after any filter() — no duplication between a manager and a queryset.

Fill in the blank so published() keeps only the rows whose status equals "published" .

❌ "QuerySet object has no attribute 'published'"

You put published() on a Manager , then called it after filter() — but filter() returns a plain QuerySet.

✅ Fix: define the method on a QuerySet subclass and use objects = PostQuerySet.as_manager() so it chains.

❌ Rows vanish from the admin after a custom manager

You overrode get_queryset() on the default objects manager, so the admin and related lookups inherited the filter.

✅ Fix: keep objects = models.Manager() unfiltered and add the filtered behaviour under a second name like live .

❌ Manager method returns a list, breaking later .filter()

Your method returned list(...) instead of a QuerySet, so chaining a queryset method afterwards fails.

✅ Fix: always return self.get_queryset().filter(...) (a QuerySet), never a materialised list.

Build a chainable QuerySet so that objects.published().recent() returns only published posts, newest first. The methods must each return a QuerySet so they can be chained.

Lesson complete — you control how your models are queried!

You now know that Model.objects is a manager and the gateway to every query, how to add methods like published() and override get_queryset() on a custom Manager , and how a chainable QuerySet subclass exposed with as_manager() lets you write Post.objects.published().recent() .

🚀 Up next: Custom Template Tags & Filters — extend the template language with your own reusable tags.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary