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

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

安装新代码

运行./manage.py syncdb && ./manage.py migrate

重新启动Web服务器并感到高兴。

下一个假设:B版本根本不起作用。它在开发中完成，但未在生产中进行，因此必须回滚。这是我必须丢失的东西。我看到两种可能性:

旧代码已重新安装。现在，向南反向迁移将是适当的，但是，这是不可能的，因为旧代码未包含回溯所需的所有最新迁移。

我们首先回滚数据库更改，然后重新安装旧代码。但是，我们如何知道A版本的最新迁移？由于一个项目可以轻松地计算出数十个应用程序，因此您需要为每个应用程序确定哪个迁移立场属于旧版本，然后分别迁移每个应用程序，然后回滚代码并希望获得最好的迁移。

在这两种情况下，我都缺少关键信息，在第一种情况下，或者在第二种情况下，都是“migration <-> version”关系。我在这里想念什么？

PS :是的，我知道我可以从备份中还原数据库，这实际上是我要做的。我想知道整个数据库迁移理论如何适合于回滚。

最佳答案

好。我认为您正在使用版本控制？在这一点上，决定“A”和“B”的组成部分非常关键。如果我们在挥手/猜测我们所引用的代码的这种乱七八糟的斑点是“A”，而这个模糊定义的东西我们都标记为“B”，那将是行不通的。

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

1)可能行不通，因为您无力杀死DB中的数据以使其从零同步
2)涉及迁移。首先，您应该在“B”而不是“A”中找到迁移。在南部，每个应用程序的所有迁移都已编号(0001、0002、0003等)。因此，假设“B”为050，而“A”为0031。 checkout “B”后，运行python manage.py migrate appname 0031，它将撤消对“B”所做的所有数据库更改。然后在版本控制系统中 checkout “A”(“A”只是提交，标记还是分支)

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