如何压制最近的Django迁移？

Question

在Django的迁移代码中,有一个squashmigrations命令:" 如果可能的话,将迁移压缩到更少的迁移,app_label包括migration_name更少的迁移."

所以,如果你想压缩前五次迁移,这将有所帮助.

从一个特定的壁球开始压制的最佳方法是migration_name什么？

在我目前正在开展的项目中,我们添加了5-10个新的迁移文件,因为我们添加了新功能.我们将立即部署整个项目,看起来单独运行这些将花费太长时间.我想将此项目的所有迁移压缩为单个迁移并测试运行时间.

Answer 1

python manage.py squashmigrations <appname> <squashfrom> <squashto>

python manage.py help squashmigrations

https://docs.djangoproject.com/en/dev/topics/migrations/#migration-squashing

这将使您能够更精细地控制哪些迁移进行压缩,并让您保持更清晰的提交历史记录.删除+重新创建所有迁移可能会导致其他问题,例如循环依赖性,具体取决于模型的构造方式.

Answer 2

您只需删除迁移文件并makemigrations再次运行即可.如果您有使用这些的开发部署,则应该迁移回删除的第一个部署之前的部署.

此外,如果出现问题,最好先提交代码.

也:

稍微复杂的是,如果有自定义RunPython代码,它将不会包含在makemigrations创建的新迁移中

Answer 3

Squash 迁移命令在 Django 1.9 中引入

如果您使用的是Django 1.8，您需要

• squashmigrations.py从Django 1.9版本 获取https://github.com/django/django/blob/stable/1.9.x/django/core/management/commands/squashmigrations.py
• 将其放在您的项目中，在/-package-/-app-/management/commands/
• 重命名为squashmigrations19.py
• 跑步./manage.py squashmigrations19 -app- 0002 0003

Answer 4

我创建了django-squash https://pypi.org/project/django-squash/作为一种不必处理每个应用程序级别的迁移或更糟糕的每个应用程序特定迁移级别的方法，并在每个应用程序级别上处理它-项目级别。我们的想法是希望在某个时候将其集成到 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/__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 的文件。Migration.operations = [..]如果您删除了所有迁移并执行了./manage.py makemigrations+ any RunSQL/ RunPythonwith ，您还会发现 a包含您所期望的一切elidable=False。如果您部署到缺少任何迁移 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

再次开始循环。