使用Django South重置迁移历史的建议方法是什么？

Question

我已经使用South（0.7）和Django（1.1.2）积累了相当多的迁移，这在我的单元测试中开始消耗相当多的时间。我想重置基线并开始一组新的迁移。我已经查看了South documentation，做了通常的Google/Stackoverflow搜索（例如“django south（reset或delete或remove）迁移历史”），但没有发现任何明显的东西。

我考虑过的一种方法是通过“删除”South或手动“清除”历史记录来“重新开始”（例如，清除db表，从migrations director中删除迁移文件），然后重新运行

./manage.py schemamigration southtut --initial

因此，如果有人以前做过，并有一些提示/建议，他们将非常感谢。

Answer 1

EDIT - I'm putting a comment below at the top of this as it's important to read it before the > accepted answer that follows @andybak

@Dominique: Your advice regarding manage.py reset south is dangerous and may destroy the database if there are any third party apps using south in the project, as pointed out by @thnee below. Since your answer has so many upvotes I'd really appreciate it if you could edit it and add at least a warning about this, or (even better) change it to reflect @hobs approach (which is just as convenient, but doesn't affect other apps) - thanks! – chrisv Mar 26 '13 at 9:09

接受的答案如下：

首先，an answer by the South author：

As long as you take care to do it on all deployments simultaneously, there shouldn't be any problem with this. Personally, I'd do:

    rm -r appname/migrations/ 
    ./manage.py reset south 
    ./manage.py convert_to_south appname 

(Notice that the “reset south” part clears migration records for ALL apps, so make sure you either run the other two lines for all apps or delete selectively).

The convert_to_south call at the end makes a new migration and fake-applies it (since your database already has the corresponding tables). There's no need to drop all the app tables during the process.

下面是我在dev+生产服务器上需要摆脱所有这些不必要的dev迁移时所做的工作：

1. 确保两边都有相同的数据库模式
2. 删除两侧的每个迁移文件夹
3. run./manage.py reset south（正如post所说）on both sides=清除south表*
4. 在两侧运行./manage.py将_转换为_south（伪造0001迁移）
5. 然后我可以重新开始进行迁移并将迁移文件夹推送到我的服务器上

*除非你只想清理一个应用程序，否则你需要编辑你的south_history表，只删除关于你的应用程序的条目。

Answer 2

如果您需要有选择地（仅针对一个应用程序）重置耗时太长的迁移，this对我有效。

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

不要忘记手动还原其他应用程序上的任何dependencies，方法是将depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial"))之类的行添加到<app-dir>/migrations/0001_initial.py文件中，作为迁移类中位于class Migration(SchemaMigration):之下的第一个属性。

然后，您可以在其他环境中，按照this SO answer进行./manage.py migrate <app-name> --fake --delete-ghost-migrations。当然，如果您伪造了delete或migrate zero，则需要使用类似this的迁移手动删除任何剩余的db表。

一个更核心的选项是在实时部署服务器上./manage.py migrate --fake --delete-ghost-migrations，然后是一个[my]sqldump。然后在您需要迁移的、完全填充的数据库的环境中将其转储到[我的]sql中。南方亵渎，我知道，但为我工作。

Answer 3

多亏了多米尼克瓜迪奥拉和霍布斯的回答，这帮我解决了一个难题。 不过，解决方案有几个问题，以下是我的看法。

使用manage.py reset south不是一个好主意如果您有任何使用South的第三方应用，例如django-cms（基本上所有应用都使用South）。

reset south将删除所有已安装应用的所有迁移历史记录。

现在考虑升级到最新版本的django-cms，它将包含像0009_do_something.py这样的新迁移。当您试图在迁移历史中不使用0001到0008来运行迁移时，South肯定会感到困惑。

选择只重置您正在维护的应用程序会更好/更安全。

---

首先，确保您的应用程序在磁盘上的迁移和数据库上执行的迁移之间没有任何去同步。否则就会头痛。

一。删除我的应用程序的迁移历史记录

sql> delete from south_migrationhistory where app_name = 'my_app';

2。删除我的应用程序的迁移

$ rm -rf my_app/migrations/

三。为我的应用程序创建新的初始迁移

$ ./manage.py schemamigration --initial my_app

四。Fake为我的应用程序执行初始迁移

这将插入到south_migrationhistory中的迁移，而不接触实际的表：

$ ./manage.py migrate --fake my_app

第3步和第4步实际上只是manage.py convert_to_south my_app的一个较长的变体，但我更喜欢这种额外的控制，在修改生产数据库这样微妙的情况下。