From ca922919f4b0ecfb5492c897e637db3457e714dd Mon Sep 17 00:00:00 2001 From: Zixuan James Li Date: Mon, 31 Oct 2022 15:29:07 -0400 Subject: [PATCH] docs: Document handling noop migrations. Inspired by #23377. We document a convention maneuver to avoid adding noop migrations, which involves modifying the latest migration related to the fields in question. Signed-off-by: Zixuan James Li --- docs/subsystems/schema-migrations.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/subsystems/schema-migrations.md b/docs/subsystems/schema-migrations.md index e289777328..3499e3858e 100644 --- a/docs/subsystems/schema-migrations.md +++ b/docs/subsystems/schema-migrations.md @@ -70,6 +70,14 @@ migrations. the entire migration in a transaction. This should make it possible to use the batch update tools in `zerver/lib/migrate.py` (originally written to work with South) for doing larger database migrations. +- **No-op migrations**. Django detects model changes that does not + necessarily lead to a schema change in the database. + For example, field validators are a part of the Django ORM, but they + are not stored in the database. When removing such validators from + an existing model, nothing gets dropped from the database, but Django + would still generate a migration for that. We prefer to avoid adding + this kind of no-op migrations. Instead of generating a new migration, + you'll want to modify the latest migration affecting the field. - **Accessing code and models in RunPython migrations**. When writing a migration that includes custom python code (aka `RunPython`), you