Migration Workflows

Both 0042 files depend on 0041, so the orders app's migration graph ends in two leaf nodes and Django refuses to guess their order. Run makemigrations --merge to add a migration depending on both, after checking they touch different fields.

dumpdata writes database rows out as a fixture (JSON by default; XML, JSONL or YAML on request) and loaddata reads fixtures back in one transaction, searching each installed app's fixtures directory, then FIXTURE_DIRS, then the current directory.

Create an empty migration with makemigrations --empty, write a function taking (apps, schema_editor) that loads the model via apps.get_model and fills the new columns, and add it to operations as migrations.RunPython, ideally with a reverse function.

apps.get_model() returns the historical model rebuilt from the migrations up to that point; an imported model is today's class, so replaying old migrations on a fresh database breaks once its fields no longer match that step's schema.

Avoid RenameField's RENAME COLUMN while old code runs. Either rename only the Python attribute and keep db_column pointing at the old column, or change the column across releases: add, write both, backfill, switch reads, then drop.

Declare the field with db_default so AddField leaves a DEFAULT on the column. With only a Python default, Django drops the column default after filling existing rows, and the old release's INSERTs, which omit the column, then fail.

migrate --fake records migrations as applied in django_migrations without running their SQL. --fake-initial fakes an app's initial migration only when its CreateModel tables and AddField columns already exist. Both are safe only when the schema really matches the migrations.

makemigrations rebuilds a project state by replaying the operations in existing migration files, builds a second state from the current models, and lets the autodetector diff the two. The database schema is never read, so manual schema changes go unnoticed.

A merge migration only joins the graph; it reconciles nothing. If both branches change the same field or model, databases can apply them in different orders and end with different schemas, so edit the migrations or add an explicit fix-up instead.

natural_key() on a model returns a tuple of unique business values; get_by_natural_key() on its default manager finds the row from that tuple. Fixtures then reference rows by stable values like an ISO code instead of database-specific ids.

loaddata saves each object with raw=True: the model's save() override is bypassed and pre_save/post_save receivers get raw=True, because related rows may not be loaded yet and derived rows are usually already in the fixture. Receivers should return early.

Django raises IrreversibleError before undoing any of that migration's operations, so the rollback stops there. RunPython.noop is right when leaving the forward change in place is harmless on the way back; otherwise write a real reverse function.

RunSQL runs raw SQL: use it for set-based updates or database features Django does not model. reverse_sql is the SQL run on unapply; state_operations tells Django's project state what schema the SQL created.

SeparateDatabaseAndState takes two lists: state_operations change Django's model state, database_operations change the real schema. It lets you change one without the other, such as removing a field from the models a release before dropping its column.

A missing column means the migration was never written or never applied. makemigrations --check fails CI when a model change lacks a migration; migrate --check fails when unapplied migrations exist; showmigrations and sqlmigrate show which migration is missing and what SQL it runs.

Renumber, making one migration 0043 that depends on the other 0042, when it has only run on disposable local databases; history stays linear. Once both ran on shared databases, merge instead: a renamed file looks unapplied and Django would run it again.

squashmigrations concatenates an app's migrations, optimizes the operations and writes one migration whose replaces lists the originals. Keep the old files until every database has applied them all; then delete them, repoint dependencies and remove replaces.

Use a data migration: migrate applies it automatically, once, in order, against the historical model state, including test databases. A fixture only loads when someone runs loaddata, uses today's models, and overwrites rows by primary key.

On PostgreSQL the whole migration is one transaction, so the table stays locked by the ALTER while the backfill runs and everything rolls back together. Split schema and data; for huge tables set Migration.atomic = False and commit batches yourself.

Replace the generated AddIndex with AddIndexConcurrently from django.contrib.postgres.operations and set atomic = False on the migration, because CREATE INDEX CONCURRENTLY cannot run in a transaction. RemoveIndexConcurrently does the same for dropping.

Require every migration to work with both the new and the previous release: additive changes ship with the code, destructive steps a release later, indexes built concurrently, backfills in separate data migrations, and each migration's SQL reviewed with sqlmigrate.

django.core.serializers turns model instances into Django's fixture format (JSON, JSONL, XML, YAML) and back, powering dumpdata and loaddata. It has a fixed model/pk/fields shape and no validation, unlike DRF serializers, which define API representations and validate input.

The squashed file references RunPython functions defined in the old numbered migration modules, which you will delete, so you copy them in by hand. Non-elidable RunPython and RunSQL also block the optimizer; elidable ones may be dropped.