Generated Columns & Keys

## The implicit primary key Every Django model has **exactly one** primary key. If no field is declared with `primary_key=True`, Django adds one when it builds the model class: ```python id = models.BigAutoField(primary_key=True) # added automatically in Django 6.x ``` It is always named **`id`**, it is an auto-incrementing integer column filled by the database, and `instance.pk` is an alias for it. Declaring any field with `primary_key=True` — or a `CompositePrimaryKey` named `pk` — stops Django adding it. ## Which class Django uses The class of that implicit field is resolved per model, from the app the model belongs to: 1. **`AppConfig.default_auto_field`** on the app's configuration class, if the class sets it; 2. otherwise the **`DEFAULT_AUTO_FIELD`** setting; 3. otherwise the setting's default, **`"django.db.models.BigAutoField"`** since Django 6.0. Django imports the dotted path and checks it. An empty value raises `ImproperlyConfigured`, a path that cannot be imported raises `ImproperlyConfigured`, and a class that is not an **`AutoField` subclass** raises `ValueError`. Valid choices are `AutoField` (32-bit), `BigAutoField` (64-bit), `SmallAutoField` (16-bit) or your own subclass of one of them. A UUID key therefore cannot be made the implicit default; it is declared explicitly on each model that wants it. | Where it is set | Scope | Typical use | |---|---|---| | `DEFAULT_AUTO_FIELD` in settings | every app without its own value | the project's house rule | | `AppConfig.default_auto_field` | one app | reusable apps; legacy apps pinned to `AutoField` | | an explicit `primary_key=True` field | one model | UUID keys, natural keys | ## What changed in Django 6.0 From Django 3.2 to 5.2 the setting existed but defaulted to `AutoField` for backwards compatibility. Instead, `startproject` wrote `DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField"` into new settings files, `startapp` wrote the same into each `AppConfig`, and projects that set nothing got system check warning **`models.W042`** ("Auto-created primary key used when not defining a primary key type"). In **Django 6.0** the default itself became `BigAutoField`, the template lines were removed, and `models.W042` no longer exists. Consequences when upgrading: - a project that followed the templates or silenced W042 by setting `BigAutoField` sees no change; - a project that never set anything was on `AutoField`; after the upgrade `makemigrations` wants to alter every implicit `id`, and every foreign key pointing at one, to a big integer. If that is not wanted now, add `DEFAULT_AUTO_FIELD = "django.db.models.AutoField"` (or `default_auto_field` on the affected apps); - auto-created many-to-many through tables are a documented gap: changing the setting migrates the related keys but not the through table's own primary key, which needs a manual `RunSQL` step. ## Reusable apps must pin it An app distributed to many projects ships its own migrations. If it relies on the project setting, a project with a different `DEFAULT_AUTO_FIELD` will generate *new* migrations inside the app's package when it runs `makemigrations`, and those can conflict with the app's future releases. The Django docs therefore say reusable apps defining models **must** set `default_auto_field` on their `AppConfig`. ## Checking what a model actually got Guessing from settings is error-prone when apps override them, so ask Django directly: - `Order._meta.pk` returns the primary key field object, and `type(Order._meta.pk).__name__` names its class; - `Order._meta.pk.name` is `"id"` for an implicit key and the declared name otherwise; - `Order._meta.pk.auto_created` is `True` only when Django added the field itself. In CI, `python manage.py makemigrations --check --dry-run` exits with an error when the models imply migrations that have not been written. After an upgrade, that is the quickest way to learn whether the new default would alter any `id` column before anyone runs `makemigrations` for real and commits dozens of unexpected `AlterField` operations. ## Why `BigAutoField` A 32-bit `AutoField` tops out at about 2.1 billion values. That sounds large until a high-volume table — events, line items, audit rows — exhausts it, at which point inserts fail and widening the column on a live table is a painful migration. A 64-bit key costs four extra bytes per key and per foreign key, which is almost always worth it; that trade-off is why the templates recommended it for years before it became the default.