In Django, what is a model Manager such as Episode.objects, and what changes when you declare a manager under another name?

## What a manager is In Django's ORM a **`Manager`** is the interface through which database queries are made for a model. Every model has at least one. When you write: ```python Episode.objects.filter(status="published") ``` `objects` is a `django.db.models.Manager` instance attached to the `Episode` class. The manager does not hold rows or a query; each call asks its **`get_queryset()`** method for a fresh `QuerySet` and forwards the call to it. So `Episode.objects.filter(...)` is, in effect, `Episode.objects.get_queryset().filter(...)`, and `Episode.objects.all()` returns `get_queryset()` directly. Django's own `Manager` class is built with `BaseManager.from_queryset(QuerySet)`, which is why almost every `QuerySet` method is callable on it. ## Manager versus QuerySet | | `Manager` (`Episode.objects`) | `QuerySet` (`Episode.objects.all()`) | |---|---|---| | Lives on | the model **class** | nowhere; created per call | | Iterable | no (`TypeError`) | yes; evaluating runs SQL | | Holds query state | no | yes: filters, ordering, result cache | | `delete()` | not available | available | | Typical use | starting point, table-level helpers | chaining filters, evaluating | `delete()` is marked `queryset_only`, so Django refuses to copy it onto managers; `Episode.objects.delete()` raises `AttributeError`, which protects you from wiping a table with one typo. Deleting everything must be spelled `Episode.objects.all().delete()`. ## Managers belong to the class Managers are **table-level**: they manage the collection of rows, not one row. Accessing one through an instance fails: - `episode.objects` raises `AttributeError: Manager isn't accessible via Episode instances`; - on an **abstract** model, managers can be defined but not called: `AbstractBase.objects.filter()` raises `AttributeError` because there is no table; - row-level behaviour belongs in **model methods**, table-level behaviour in managers or custom QuerySets. ## Naming: `objects` is only a default Django adds a manager named `objects` **only if the model and its parents declare no manager at all**. The rules: 1. No manager declared: Django adds `objects = models.Manager()` for you. 2. Any manager declared, under any name: no automatic `objects`. 3. A model **field** named `objects` with no custom manager: Django raises `ValueError` ("must specify a custom Manager, because it has a field named 'objects'"). So this model has no `objects`: ```python class Episode(models.Model): title = models.CharField(max_length=200) catalog = models.Manager() ``` `Episode.catalog.all()` works; `Episode.objects` raises `AttributeError`. People rename the manager when `objects` is taken by a field, or to make a domain word read well, but most teams keep `objects` as the plain manager and **add** extra managers next to it, so code and third-party apps that assume `objects` keep working. ## Several managers on one model A model may declare more than one manager, each with its own `get_queryset()`: ```python class Episode(models.Model): objects = models.Manager() published = PublishedManager() # get_queryset() filters status="published" ``` - `Episode.objects.all()` returns every episode; - `Episode.published.all()` returns only published ones; - the **first** declared manager becomes the model's **default manager**, which matters to the admin, `dumpdata` and related lookups, so the order of declaration is not cosmetic. ## Custom managers: extra methods and a new starting set There are two reasons to write a `Manager` subclass, and they can be combined: - **Add table-level methods.** A method such as `create_draft(podcast, title)` or `import_feed(url)` acts on the collection, not on one row, so it belongs on the manager. It may return anything: an instance, a count, a QuerySet. - **Change the initial QuerySet** by overriding `get_queryset()`, for example `return super().get_queryset().filter(status="published")`. Every call through that manager, including `all()`, then starts from the filtered set. Row-level behaviour, such as `episode.duration_display()`, stays a model method. A manager must also be shallow-copyable, because Django copies managers internally (for example in `db_manager()`); simple subclasses are, but overriding `__getattr__` can break that. ## What to say in an interview - A manager is the class-level gateway; a QuerySet is the lazy, chainable query it hands out. - `objects` is auto-added only when nothing else is declared. - Managers are not reachable from instances and cannot `delete()` directly. - For reusable filters, the modern answer is a custom `QuerySet` exposed with `as_manager()`, because methods defined only on a manager cannot be chained after `filter()`.