Database 与South的回滚应该如何工作？

把我弄糊涂了。让我们假设我们有一个Django项目，有南迁。目前，生产项目版本为

A

，开发中的版本为

B

。现在，让我们假设生产中安装了版本

B

：

安装新代码

运行

/manage.py syncdb&./manage.py migrate

重新启动web服务器并保持愉快

下一个假设：版本

B

根本不起作用。它在开发过程中使用过，但在生产过程中没有，因此必须回滚。这就是我一定错过了什么的地方。我认为有两种可能性：

重新安装中的旧代码。现在，南回迁移是合适的，但是，这是不可能的，因为旧代码不包含返回所需的所有最新迁移

我们首先回滚数据库更改，然后重新安装旧代码。但是，我们如何知道版本

A

的最新迁移？由于一个项目可以轻松计算出几十个应用程序，因此您需要为每个应用程序计算出哪个迁移站属于旧版本，然后分别迁移每个应用程序，然后回滚代码，并期待最好的结果

在这两种情况下，我都缺少关键信息，第一种情况下是迁移代码，第二种情况下是“migration

version”关系。我错过了什么

---

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

好的。我想您正在使用版本控制？？这对于确定“A”和“B”的组成非常关键。如果我们手舞足蹈/猜测我们引用的这一堆乱七八糟的代码是“A”，而这另一个定义模糊的东西我们都称之为“B”，那就行不通了

如果您试图将“A”重新安装到“B”的位置，则有两个选项： 1） 从零开始签出并重新生成“A”（同步和迁移） 2） 将“B”滚回“A”

1） 很可能无法工作，因为您无法通过删除数据库中的数据来同步数据 2） 包括迁移。首先，您应该在“B”中找到迁移，而不是在“A”中。在南方，每个应用程序的所有迁移都有编号（0001、0002、0003等）。假设‘B’在050，而‘A’在0031。签出“B”后，运行将撤消对“B”所做的所有DB更改的

python manage.py migrate appname 0031

。然后在版本控制系统中签出“A”（无论“A”是提交还是标记或分支）

---

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

不确定这是否是您的选择，但您不能在将代码移回“a”版本之前在生产中运行向后迁移吗？这样，您的数据库将返回到进行syncdb之前的任何迁移，然后您将代码更改回版本A，您就回到了开始的位置。

本质上，这就是我所描述的第二种可能性——大量的手动工作和某种程度上挫败了整个向后迁移过程，由于从备份中恢复数据库更容易，而且可能更快：（编写获取所需迁移文件并运行它们的脚本一点也不难。从备份中恢复似乎要慢得多——尤其是随着数据库的增长。一个更简单的解决方案可能是让South能够以

pip freeze

的方式转储一个文本文件列表，其中列出了数据库当前所在的位置。这可能会发生s只包含所有的

/manage migrate myapp xxxx

命令。您可以在处理新分支时转储并保存输出，然后在想要回滚时运行它。我想您可以在提交后命名文件。现在可以编写脚本来解析

/manage migrate--list

的输出并执行此操作。