makemigrations and migrate

Two commands, two jobs, on purpose.

makemigrations compares your models with the migrations so far and writes a file describing the difference. Nothing touches the database.

migrate runs the migrations that have not been applied yet.

Separating them means you can read the plan before it runs, and it means the same plan runs identically on your machine, on a colleague's, and in production.

SANKOFA SANDBOX

The rhythm of working with migrations. This shell is a sandbox, so nothing here touches a real database.

learner:/journal$

Real Django would write a numbered file into that migrations folder. The point here is the shape: models change, a migration is written, then it is applied.

Try it → Look inside posts/migrations. Then create a file named 0001_initial.py in it, which is what makemigrations would have produced.

Migrations are source code. Commit them. Never edit one that has already been applied anywhere.

If you change a model and do not make a migration, the database no longer matches your code. The error that follows appears somewhere else entirely, usually as a column that does not exist, and it is genuinely hard to trace back.

✦ The default prompt is not a bug

Add a field that cannot be empty to a table with rows in it, and Django stops and asks what those existing rows should contain. It cannot invent an answer. Either supply a default, or make the field nullable, or add it in two steps: nullable first, backfill, then tighten it.

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Seeing What It Actually Does →

← Back