Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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 <p359101898@gmail.com>
This commit is contained in:
Zixuan James Li 2022-10-31 15:29:07 -04:00 committed by Tim Abbott
parent 888e4f9bf4
commit ca922919f4
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/subsystems/schema-migrations.md
View File

@ -70,6 +70,14 @@ migrations.
the entire migration in a transaction. This should make it possible the entire migration in a transaction. This should make it possible
to use the batch update tools in `zerver/lib/migrate.py` (originally to use the batch update tools in `zerver/lib/migrate.py` (originally
written to work with South) for doing larger database migrations. 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 - **Accessing code and models in RunPython migrations**. When writing
a migration that includes custom python code (aka `RunPython`), you a migration that includes custom python code (aka `RunPython`), you