我使用South(0.7)和Django(1.1.2)积累了相当多的迁移，它们开始在我的单元测试中消耗大量的时间。我想重新设置基线并开始一组新的迁移。我查看了South文档，完成了通常的Google/StackOverflow搜索(例如"Django South(重置或删除或删除)迁移历史")，没有发现任何明显的内容。

我设想的一种方法是"重新开始"，通过"删除"南方或"清除"历史记录(例如，清除数据库表，从迁移控制器中删除迁移文件)，然后重新运行，

./manage.py schemamigration southtut --initial

号

因此，如果有人以前做过这些，并且有一些建议/建议，他们会非常感激。

如果你需要有选择地(只为一个应用程序)重置耗时太长的迁移，这对我很有效。

不要忘记手动恢复对其他应用程序的依赖性，方法是在您的/migrations/0001_initial.py文件中添加诸如depends_on = (("","0001_initial"),("","0001_initial"))这样的行，作为迁移类中位于class Migration(SchemaMigration):正下方的第一个属性。

然后，您可以在其他环境中使用./manage.py migrate --fake --delete-ghost-migrations，根据这样的答案。当然，如果您伪造删除或伪造migrate zero，那么您需要通过这样的迁移手动删除任何剩余的db表。

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

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

号

接受的回答如下：

首先，南方作家的回答是：

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:

1 2 3

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+生产服务器上所做的：

确保两边都有相同的DB模式

删除两侧的每个迁移文件夹

run./manage.py reset south(如文章所述)on both sides=清除南表*

运行./manage.py在两侧将_转换为_South(伪造0001迁移)

然后我可以重新开始迁移并推送服务器上的迁移文件夹

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

相关讨论

• 就记录而言，南方作者的回答是：只要您同时在所有部署中都注意到这一点，就不会有任何问题。我个人会这样做：rm-r appname/migrations//manage.py reset south./manage.py convertu to south appname(注意，"reset south"部分清除所有应用程序的迁移记录，因此请确保为所有应用程序运行其他两行或删除selective)。
• 还要注意，如果您删除了表，那么您需要manage.py schemamigration app name --initial，而不是将_转换为_South。
• 从Django 1.5开始，"重置"管理命令消失。相反，您将要做一些大致类似于south.models.MigrationHistory.objects.all().delete()的事情。
• @多米尼克：你关于manage.py reset south的建议是危险的，如果项目中有任何第三方应用程序在使用south，可能会破坏数据库，如下面@thnee所指出的。既然你的答案有这么多的赞成票，如果你能编辑它并至少添加一个关于这个的警告，或者(甚至更好)更改它以反映@hobs方法(这是同样方便，但不影响其他应用程序)，我会非常感激-谢谢！
• 为什么这次投票如此之高？您几乎不应该完全删除您的South_MigrationHistory表。这将彻底破坏任何你不想接触的迁移的依赖应用程序。霍布的回答是正确的。
• @Cerin不是为什么评论说"注意到"reset south"部分清除了所有应用程序的迁移记录，所以请确保对所有应用程序运行其他两行或有选择地删除"，还是提出了不同的问题？
• 除了@chrisv的评论，它还应该更清楚地表明，reset south不仅仅对第三方应用程序有危险。它将删除项目所有应用程序的迁移历史记录。@Hobs每个应用程序都有一个最佳解决方案。
• 当我尝试"./manage.py reset south"时，我得到了未知的命令："reset"type"manage.py help"了解用法。

---

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

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

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

现在考虑升级到最新版本的django-cms，它将包含新的迁移，如0009_do_something.py。当你试图在移民历史上不让0001通过0008的情况下进行移民时，南方肯定会感到困惑。

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

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

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

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

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

1	$ rm -rf my_app/migrations/

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

1	$ ./manage.py schemamigration --initial my_app

。4。假执行应用程序的初始迁移

这将在不接触实际表的情况下插入到south_migrationhistory中的迁移：

1	$ ./manage.py migrate --fake my_app

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

相关讨论

• 我编辑了我的答案，将对您发现的问题的修复(根据您的答案进行猜测)，并在具有数百万行的生产数据库中对其进行了测试。
• 太棒了。谢谢
• 这就是我们正在做的。如果在步骤4中使用--delete ghost migrations选项，则可以省略步骤1。
• 如果您不想伪造迁移挂起的其他应用程序，那么应该在./manage.py migrate --fake中明确指定应用程序名称。
• @因此，wadim步骤0："确保在磁盘上的迁移和在数据库上执行的迁移之间没有去同步"。
• @没错。可能值得一提的是，您在步骤0中引用了所有已安装的应用程序。但是，您知道执行步骤0的简单方法吗？
• @瓦迪姆：是的，埃多克斯1〔7〕。
• @你能解释一下"删除自"这个词吗，说明使用的工具？
• @bryce"delete from"是在数据库外壳程序中执行的原始SQL。
• 数据迁移呢？

---

像thnee(见她的答案)一样，我们对本文其他地方引用的South Author(Andrew Godwin)建议使用了更温和的方法，我们将代码库的处理与部署期间对数据库的处理分开，因为我们需要可重复的部署：

我们在代码中所做的：

1 2 3 4

# Remove all the migrations from the app $ rm -fR appname/migrations # Make the first migration (don't touch the database) $ ./manage.py schemamigration appname --initial

一旦部署了代码，我们将如何处理数据库

1 2	# Fake the migration history, wiping out the rest $ ./manage.py migrate appname --fake --delete-ghost-migrations

号

相关讨论

• 我想我也做了同样的事情，但是手动删除数据库条目，而不是使用--delete-ghoist-migrations。你的方式好多了。

---

如果您只是在开发机器上工作，我编写了一个管理命令，它执行Dominique建议的大部分操作。

网址：http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

与South作者的建议相反，这不会损害使用South的其他已安装应用程序。

相关讨论

• 如果与作者不同，您希望保留现有迁移(即，您希望重置应用程序以及迁移历史记录，但保留实际迁移)，则可以尝试以下操作：goo.gl/0znwm
• +1表示想法，-1表示代码的可读性

---

从应用文件夹中删除必要的文件

实例路径

1	cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations

wiki-是我的应用程序

---

只有当您想重置所有应用程序时，才能执行以下操作。在这项工作之前，请备份您的所有数据库。另外，请注意初始文件中的依赖项(如果有)。

一次：

1 2 3 4

(1) find . -type d -name migrations -exec git rm -rf '{}' \; (2) find . -type d -name migrations -exec rm -rf '{}' \; (3) ./manage.py schemamigration <APP_NAME> --initial (4) [GIT COMMIT]

。

在推送之前测试引导您的项目。然后，对于每个本地/远程机器，应用以下方法：

1 2 3

(5) [GIT PULL] (6) ./manage.py reset south (7) ./manage.py migrate --fake

。

为每个你想要重新参与的应用程序做首字母(3)。请注意，reset(6)将只删除迁移历史记录，因此不会对库造成损害。假迁移(7)将恢复安装的任何第三方应用程序的迁移历史记录。

---