South：如何恢复生产服务器中的迁移？

Question

我想通过运行 Migration.backwards() 方法来恢复我上次的迁移 (0157)。由于我正在恢复生产服务器中的迁移，因此我想在代码部署期间自动运行它。部署脚本执行以下步骤：

1. 拉取代码更改
2. 运行迁移：manage.py migrate <app>
3. 刷新 Apache 以使用最新代码：touch django.wsgi

如果可以的话，我会创建 新的迁移文件，告诉 South 向后迁移到 0156：

migrations/0158_backward__migrate_to_0156.py

此提交的迁移将部署到生产环境并在manage.py migrate <app> 命令期间执行。在这种情况下，我不必像 these answers 中建议的那样手动执行向后迁移。

可以说，我创建了两个数据迁移，第一个用于用户的支付，第二个用于用户模型。我已经为这两种迁移实现了 backwards() 方法，以防我不得不恢复这些数据迁移。我已将这两个迁移部署到生产环境。突然发现支付迁移有错误。我想尽快恢复我最后的两次数据迁移。最快安全的方法是什么？

Answer 1

由于我要在生产服务器中恢复迁移，因此我想运行 它会在代码部署期间自动进行。

恕我直言，最安全的路径是

1. 运行 manage.py migrate <app>（即应用所有现有迁移，即最多 0156）
2. 撤消模型中的更改
3. 运行manage.py schemamigration <app> --auto

这将创建一个新的迁移 0157，它有效地恢复了之前的迁移 0156。然后只需再次运行 manage.py migrate <app> 即可应用新的迁移。据我了解，您的代码部署就是这样做的。

Answer 2

显然，代码线已迁移到 #157，现在开发人员认为最后一个毕竟不是一个好主意。所以计划是回到#156。

两种情况：

(a) 迁移 #157 尚未在任何地方发布或部署。 只需从 models.py 中恢复上一次更改并从源存档中删除迁移 #157.py。任何部署都会将系统提升到 156 级； “157 从来没有出现过”。

(b) 已经部署了带有迁移 #157 的最新软件。 在这种情况下，前面的策略显然行不通。因此，您需要创建迁移 #158 以撤消 #157。还原 models.py 中的更改并运行

django manage.py migrate <app> 0157
django manage.py schemamigration <app> --auto

这将自动生成一个新的迁移 #158，其中将包含与 #157 相比的反向架构迁移。

如果由于 django 模型验证而导致 schemamigration 出现问题（如果您有自定义验证器来检查 ORM 框之外的内容，则可能会发生这种情况），我建议采用以下解决方法：

<django project>/<app>/management/commands/checkmigrations.py

from south.management.commands import schemamigration
class Command(schemamigration.Command):
    requires_model_validation = False
    help = "schemamigration without model validation"

此命令在 manage.py 中可用：

django manage.py checkmigrations <app> --auto

Answer 3

这里没有灵丹妙药。我能想到的最简单的解决方案是——当然是在你的开发环境中——手动迁移回 0156，手动更新你的迁移历史表（对不起，我现在不记得表的名字了）来愚弄南方，以为你是仍然是 @0158，然后再次运行 schemamigration。不保证工作，但可能值得一试。