In Django, what is the ContentType model, and what does ContentType.objects.get_for_model() give you?

juniorshould knowfreq 30%

answer

a table listing every model
app_label plus lowercase model name
created after migrate runs
cached per process and database

basics

~20 s

ContentType is the contenttypes app's registry: one row per installed model, identified by app_label and model name. get_for_model() returns that row for a model class or instance, creating it if missing and caching it in-process.

solid answer

~30 s

django.contrib.contenttypes keeps the table django_content_type, with one ContentType row per model identified by app_label and the lowercase model name, so every model has an integer id that other tables can store. Rows are bulk-created by a post_migrate handler after migrate. ContentType.objects.get_for_model(model) takes a class or an instance and returns its row; it creates the row if it is missing and caches it per process and database, so repeated calls cost no query. From a row, model_class() gives the Python class back and get_object_for_this_type(**kwargs) fetches one object. Auth permissions and generic relations are both built on this registry.

`django.contrib.contenttypes` keeps the table `django_content_type`, with one `ContentType` row per model identified by `app_label` and the lowercase `model` name, so every model has an integer id that other tables can store. Rows are bulk-created by a `post_migrate` handler after `migrate`. `ContentType.objects.get_for_model(model)` takes a class or an instance and returns its row; it creates the row if it is missing and caches it per process and database, so repeated calls cost no query. From a row, `model_class()` gives the Python class back and `get_object_for_this_type(**kwargs)` fetches one object. Auth permissions and generic relations are both built on this registry.

code

python · 9 lines

python

from django.contrib.contenttypes.models import ContentType

from photos.models import Photo

ct = ContentType.objects.get_for_model(Photo)   # one query at most, then cached
ct.app_label, ct.model                          # ('photos', 'photo')
ct.model_class() is Photo                       # True
photo = ct.get_object_for_this_type(pk=42)      # raises Photo.DoesNotExist if absent
same = ContentType.objects.get_for_id(ct.id)    # served from the shared cache

go deeper

for a junior

Recall that django_content_type holds one row per model, keyed by app_label and model name, and that get_for_model() returns it.

for a middle

Explain the in-process cache, the post_migrate creation, and why get_for_id() beats a plain get(pk=...).

for a senior

Show you have been bitten by per-database ids and stale rows: natural keys in fixtures, and care before running remove_stale_contenttypes with --noinput.

for a principal

Weigh how much of the codebase should depend on content types at all, given that the ids are environment-specific and every generic link inherits that fragility.

What the contenttypes framework is

django.contrib.contenttypes is a contrib app, present in the INSTALLED_APPS of the default project template, that keeps a registry of every model in the project. It exists so that one table can refer to a kind of model rather than to one fixed model. Two Django features build directly on it: the auth Permission model, which points at a content type to say which model a permission concerns, and generic relations, which store a content type plus a primary key to point at a row in any table.

The ContentType row

The registry is an ordinary model, ContentType, stored in the table django_content_type. Each row has:

an integer primary key, the value other tables store;
app_label, the app's label, such as photos;
model, the model's lowercase name, such as photo.

The pair (app_label, model) is unique, so one model has exactly one row per database. A row also knows how to get back to Python code:

model_class() returns the model class, or None if the model no longer exists in the code;
get_object_for_this_type(**kwargs) runs a get() on that model's base manager and lets DoesNotExist propagate to the caller;
get_all_objects_for_this_type(**kwargs) returns a filtered queryset;
natural_key() returns (app_label, model).

The manager methods

ContentType.objects is a ContentTypeManager with a shared in-process cache, keyed first by database alias, then by both (app_label, model) and id.

Method	Returns	Notes
`get_for_model(model, for_concrete_model=True)`	the row for a class or instance	creates the row if missing; cached
`get_for_models(*models, for_concrete_models=True)`	a dict of model to row	one query for all uncached models
`get_for_id(id)`	the row with that id	shares the cache; never creates
`get_by_natural_key(app_label, model)`	the row	used when loading fixtures
`clear_cache()`	nothing	empties the cache

Because of the cache, calling get_for_model(Photo) inside a loop costs at most one query the first time in a process and none afterwards. The docs recommend get_for_id() over ContentType.objects.get(pk=...) for the same reason: the plain get() bypasses the cache.

When rows appear, change and disappear

Creation. The contenttypes app connects a handler to the post_migrate signal. After migrate runs, it bulk-creates a row for every model of each app that lacks one, proxy models included. get_for_model() also creates a missing row on demand.
Renaming. When a migration contains a RenameModel operation, contenttypes injects an extra operation (through a pre_migrate handler) that renames the matching row, so its id, and everything pointing at that id, survives the rename.
Removal. Rows for deleted models are not removed automatically. The management command remove_stale_contenttypes deletes rows whose model_class() is None; add --include-stale-apps to cover apps removed from INSTALLED_APPS. Deleting a content type cascades to anything holding a real foreign key to it, such as permissions or rows of a generic-link model, which is why the command lists the dependent objects and asks for confirmation.

Proxy models and for_concrete_model

A proxy model shares its parent's table. By default get_for_model(ProxyPhoto) returns the concrete model's row, because for_concrete_model=True swaps the proxy for its concrete parent before the lookup. Pass for_concrete_model=False to get the proxy's own row, which exists because the post-migrate handler registers proxies too. The same flag appears on GenericForeignKey and GenericRelation and decides whether a generic link records the proxy or the concrete model.

Pitfalls interviewers look for

Ids are per database. The same model can have id 7 in development and id 12 in production, depending on the order in which rows were created. Never hard-code a content type id; serialize references with natural keys (dumpdata --natural-foreign).
The cache outlives the rows. The cache is process-wide, so a test that creates or removes content types can leave stale entries; the docs show ContentType.objects.clear_cache() in a test's setUp with an addCleanup for exactly this.
Stale rows break code. A leftover row makes model_class() return None, and code that immediately calls a method on the result raises AttributeError.
It is a lookup table, not a model definition. Nothing about fields or columns lives in django_content_type; the schema still comes from models and migrations.

## What the contenttypes framework is `django.contrib.contenttypes` is a contrib app, present in the `INSTALLED_APPS` of the default project template, that keeps a **registry of every model** in the project. It exists so that one table can refer to *a kind of model* rather than to one fixed model. Two Django features build directly on it: the auth `Permission` model, which points at a content type to say which model a permission concerns, and **generic relations**, which store a content type plus a primary key to point at a row in any table. ## The ContentType row The registry is an ordinary model, `ContentType`, stored in the table `django_content_type`. Each row has: - an integer **primary key**, the value other tables store; - `app_label`, the app's label, such as `photos`; - `model`, the model's lowercase name, such as `photo`. The pair (`app_label`, `model`) is unique, so one model has exactly one row per database. A row also knows how to get back to Python code: - `model_class()` returns the model class, or `None` if the model no longer exists in the code; - `get_object_for_this_type(**kwargs)` runs a `get()` on that model's base manager and lets `DoesNotExist` propagate to the caller; - `get_all_objects_for_this_type(**kwargs)` returns a filtered queryset; - `natural_key()` returns `(app_label, model)`. ## The manager methods `ContentType.objects` is a `ContentTypeManager` with a **shared in-process cache**, keyed first by database alias, then by both `(app_label, model)` and id. | Method | Returns | Notes | |---|---|---| | `get_for_model(model, for_concrete_model=True)` | the row for a class or instance | creates the row if missing; cached | | `get_for_models(*models, for_concrete_models=True)` | a dict of model to row | one query for all uncached models | | `get_for_id(id)` | the row with that id | shares the cache; never creates | | `get_by_natural_key(app_label, model)` | the row | used when loading fixtures | | `clear_cache()` | nothing | empties the cache | Because of the cache, calling `get_for_model(Photo)` inside a loop costs at most one query the first time in a process and none afterwards. The docs recommend `get_for_id()` over `ContentType.objects.get(pk=...)` for the same reason: the plain `get()` bypasses the cache. ## When rows appear, change and disappear 1. **Creation.** The contenttypes app connects a handler to the `post_migrate` signal. After `migrate` runs, it bulk-creates a row for every model of each app that lacks one, proxy models included. `get_for_model()` also creates a missing row on demand. 2. **Renaming.** When a migration contains a `RenameModel` operation, contenttypes injects an extra operation (through a `pre_migrate` handler) that renames the matching row, so its id, and everything pointing at that id, survives the rename. 3. **Removal.** Rows for deleted models are *not* removed automatically. The management command `remove_stale_contenttypes` deletes rows whose `model_class()` is `None`; add `--include-stale-apps` to cover apps removed from `INSTALLED_APPS`. Deleting a content type cascades to anything holding a real foreign key to it, such as permissions or rows of a generic-link model, which is why the command lists the dependent objects and asks for confirmation. ## Proxy models and for_concrete_model A proxy model shares its parent's table. By default `get_for_model(ProxyPhoto)` returns the **concrete** model's row, because `for_concrete_model=True` swaps the proxy for its concrete parent before the lookup. Pass `for_concrete_model=False` to get the proxy's own row, which exists because the post-migrate handler registers proxies too. The same flag appears on `GenericForeignKey` and `GenericRelation` and decides whether a generic link records the proxy or the concrete model. ## Pitfalls interviewers look for - **Ids are per database.** The same model can have id 7 in development and id 12 in production, depending on the order in which rows were created. Never hard-code a content type id; serialize references with natural keys (`dumpdata --natural-foreign`). - **The cache outlives the rows.** The cache is process-wide, so a test that creates or removes content types can leave stale entries; the docs show `ContentType.objects.clear_cache()` in a test's `setUp` with an `addCleanup` for exactly this. - **Stale rows break code.** A leftover row makes `model_class()` return `None`, and code that immediately calls a method on the result raises `AttributeError`. - **It is a lookup table, not a model definition.** Nothing about fields or columns lives in `django_content_type`; the schema still comes from models and migrations.

What does remove_stale_contenttypes do, and why is it risky on a production database?
It deletes `ContentType` rows whose `model_class()` is `None`, meaning the model is gone from the code; `--include-stale-apps` also covers apps removed from `INSTALLED_APPS`. Deleting a content type cascades through real foreign keys to it, so permissions and any generic-link rows for that model go too. Interactively it lists the dependent objects first; with `--noinput` it deletes without asking.
Why should a data migration or fixture never store a raw ContentType id?
Ids are assigned in the order rows are created on each database, so the same model can have different ids in development, CI and production. Look the row up by `get_for_model()` or `get_by_natural_key(app_label, model)` at run time, and dump fixtures with `--natural-foreign` so references are written as `(app_label, model)` pairs.

saying these in an interview costs you the question

You must create a ContentType row by hand for each new model
get_for_model() runs a database query on every call
A model's ContentType id is identical on every database
get_for_model() on a proxy returns the proxy's own row by default
Deleting a stale content type only removes the registry row

In Django, what is the ContentType model, and what does ContentType.objects.get_for_model() give you?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the contenttypes framework is

The ContentType row

The manager methods

When rows appear, change and disappear

Proxy models and for_concrete_model

Pitfalls interviewers look for

▾common follow-ups2 questions

▾red flags5 flags

What the contenttypes framework is

The ContentType row

The manager methods

When rows appear, change and disappear

Proxy models and for_concrete_model

Pitfalls interviewers look for

answer

go deeper