我创建了django-squash https://pypi.org/project/django-squash/ 是为了不必在每个应用级别或更糟的每个应用特定迁移级别上处理迁移,而是在每个项目级别上处理它。这个想法是希望在某个时候将它集成到核心 Django 中。
基本思路:
- 您有一个产品,没有其他人可以改进的开源产品,但您的产品,您的团队,您来处理它。
- 在每个版本之后,您都希望压缩您在上一个版本中所做的所有迁移并开始一个新版本,因为您的产品已经从上一个版本和您的数据模型演变而来。
- 你 squash,它会查看你之前是否已经 squash,如果有,它会删除所有在你的代码库中没有业务的非常旧的迁移。最后,为您的迁移创建一个新快照,并保留您现有的迁移。
- 您将在每个版本/当您觉得运行所有迁移的测试花费太长时间时执行此操作。
例子:
/app1/migrations/__init__.py
/app1/migrations/0001_initial.py
/app1/migrations/0002_created_user_model.py
/app1/migrations/0003_added_username.py
/app1/migrations/0004_added_password.py
/app1/migrations/0005_last_name.py
你已经全部应用了。
但每次运行测试时,都需要运行其中的每一个步骤,这会花费宝贵的时间。所以我们压扁。新目录将如下所示:
/app1/migrations/__init__.py
/app1/migrations/0001_initial.py
/app1/migrations/0002_created_user_model.py
/app1/migrations/0003_added_username.py
/app1/migrations/0004_added_password.py
/app1/migrations/0005_last_name.py
/app1/migrations/0006_squash.py
在0006_squash.py 中,您会发现replaces = [..] 带有迁移1-5 的名称。如果您删除所有迁移并执行./manage.py makemigrations + 任何RunSQL/RunPython 和elidable=False,您还将找到一个Migration.operations = [..],其中包含您所期望的一切。如果您部署到缺少任何迁移 1-5 的环境,它将从源应用它而不使用 0006。 (这是标准的 Django 迁移)
一段时间过去了,现在您的迁移看起来像这样:
/app1/migrations/__init__.py
/app1/migrations/0001_initial.py
/app1/migrations/0002_created_user_model.py
/app1/migrations/0003_added_username.py
/app1/migrations/0004_added_password.py
/app1/migrations/0005_last_name.py
/app1/migrations/0006_squash.py
/app1/migrations/0007_change_username_to_100_char.py
/app1/migrations/0008_added_dob.py
你又压扁了。这次会发生以下情况。 replaces = [..] 中的任何内容都将被删除。 0006_squash.py 将被修改为使 replaces 为空列表。最后,将使用新的更改重新创建壁球。总而言之,将如下所示:
/app1/migrations/0006_squash.py
/app1/migrations/0007_change_username_to_100_char.py
/app1/migrations/0008_added_dob.py
/app1/migrations/0009_squash.py
再次开始循环。