4

让我感到困惑。假设我们有一个带有 South 迁移的 Django 项目。目前，生产项目版本为A, version in development B。现在让我们假设版本B已安装到生产中：

  1. 安装新代码
  2. 跑./manage.py syncdb && ./manage.py migrate
  3. 重新启动网络服务器并感到高兴。

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

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

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

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

4

2 回答 2

4

好的。我想你正在使用版本控制？在这一点上，这对于确定“A”和“B”的构成非常重要。如果我们挥手/猜测我们引用的这个无定形的代码块是“A”，而另一个我们都标记为“B”的模糊定义的东西 - 它不会起作用。

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

1) 可能无法正常工作，因为您无法杀死数据库中的数据以从无到有同步 2) 涉及迁移。首先，您应该在“B”而不是“A”中找到迁移。在南方，每个应用程序的所有迁移都有编号（0001、0002、0003 等）。因此，假设“B”位于 050，“A”位于 0031。当您签出“B”时，运行python manage.py migrate appname 0031这将撤消您为“B”所做的所有数据库更改。然后在您的版本控制系统中签出“A”（“A”是否只是提交、标签或分支）

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

于 2011-01-14T14:33:31.360 回答
1

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

于 2011-09-05T02:30:16.870 回答