database - South 的回滚应该如何工作？

Question

让我感到困惑。假设我们有一个向南迁移的 Django 项目。目前，生产项目版本为 A , 开发中的版本 B .现在让我们假设版本 B已安装到生产环境中:

1. 安装新代码
2. 运行 ./manage.py syncdb && ./manage.py migrate
3. 重新启动网络服务器并开心。

下一个假设:版本B根本不起作用。它在开发中做了，但在生产中没有，所以它必须回滚。这就是我必须遗漏的地方。我看到两种可能性:

1. 已重新安装旧代码。现在，南向迁移是合适的，但是，这是不可能的，因为旧代码不包含返回所需的所有最新迁移。
2. 我们首先回滚数据库更改，然后重新安装旧代码。但是，我们如何知道版本 A 的哪个迁移是最新的？ ？由于一个项目可以很容易地包含几十个应用程序，因此您需要为每个应用程序弄清楚哪个迁移站属于旧版本，然后分别迁移每个应用程序，然后回滚代码并希望最好。

在这两种情况下，我都缺少关键信息，第一种情况是迁移代码，第二种情况是“迁移 <-> 版本”关系。我在这里缺少什么？

PS:是的，我知道我可以从备份中恢复数据库，这就是我实际做的。我想知道整个数据库迁移理论如何适应回滚。

Answer 1

好的。我假设您正在使用版本控制？在这一点上，确定什么构成“A”和“B”非常关键。如果我们挥手/猜测我们引用的这个无定形的代码块是“A”，而这个其他定义模糊的东西我们都标记为“B”——它是行不通的。

如果您尝试在“B”的位置重新安装“A”，您有两个选择:1)从头开始检查并重建“A”(同步和迁移)2) 将“B”滚回“A”。

1) 可能行不通，因为您无力杀死数据库中的数据以从无到有进行同步2)涉及迁移。首先，您应该在“B”而不是“A”中找到迁移。在南部，每个应用程序的所有迁移都有编号(0001、0002、0003 等)。所以假设“B”在 050，“A”在 0031。当你 checkout “B”时，运行 python manage.py migrate appname 0031 这将撤消所有数据库更改你为“B”制作。然后在你的版本控制系统中你检查'A'(无论'A'只是一个提交或一个标签或一个分支)

不幸的是，您不能回滚到“A”然后说“取消迁移所有您没有的东西”。这将是一个更简单的解决方案 - 但是您需要迁移系统来了解您的版本控制系统，这有点麻烦。