5

我想通过运行它的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>命令期间执行。在这种情况下，我不必像这些答案中建议的那样手动执行向后迁移。

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

4

3 回答 3

3

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

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

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

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

于 2014-01-26T00:49:38.213 回答
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
于 2014-01-23T13:27:54.207 回答
1

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

于 2013-12-23T18:56:12.887 回答