迁移文件积累到几百个,新环境 migrate 很慢。squashmigrations 能压缩它们,但已经部署的库怎么办?这篇把「新旧迁移共存」时的三种状态都验证一遍。
0001_initial: ['CreateModel'] 0002_p_a: ['AddField'] 0003_p_b: ['AddField'] 0004_alter_p_name: ['AlterField'] 0005_p_c: ['AddField']
五个迁移,每个操作都很小。
Will squash the following migrations:
- 0001_initial
- 0002_p_a
- 0003_p_b
- 0004_alter_p_name
- 0005_p_c
Optimizing...
Optimized from 5 operations to 1 operations.
Created new squashed migration <实验目录>
You should commit this migration but leave the old ones in place;
the new migration will be used for new installs. Once you are sure
all instances of the codebase have applied the migrations you squashed,
you can delete them.
合并后的文件: 0001_initial_squashed_0005_p_c.py 操作: ['CreateModel'] replaces: [('lab','0001_initial'),('lab','0002_p_a'),('lab','0003_p_b'),('lab','0004_alter_p_name'),('lab','0005_p_c')]squashmigrations app 0001 0005 生成新文件并保留旧文件。合并迁移里的 replaces 列出被替代的迁移。官方建议的流程:提交合并迁移 → 等所有环境都应用了旧迁移 → 删除旧迁移并把合并迁移的 replaces 去掉(后两步本文没有做)。
全新数据库: ['lab.0001_initial_squashed_0005_p_c'] 已经应用到 0003 之后 django_migrations: ['0001_initial', '0002_p_a', '0003_p_b'] 这时 migrate --plan: ['lab.0004_alter_p_name', 'lab.0005_p_c'] 全部 migrate 之后 django_migrations: ['0001_initial', '0002_p_a', '0003_p_b', '0004_alter_p_name', '0005_p_c', '0001_initial_squashed_0005_p_c'] 再 migrate --plan: (无事可做)
规则(实测):如果 replaces 里的迁移在数据库里要么全部应用要么全部没应用,就用合并迁移;部分应用则用旧迁移,直到全部应用后 Django 会补一条合并迁移自己的记录。
SQL 语句数:五个旧迁移合计 17 条;合并后的 0001_initial_squashed_0005_p_c 1 条
SQL 条数是 SQLite 上的(它对每次改列都重建表),PostgreSQL 上收益要小一些。