Question

我使用South（0.7）和Django（1.1.2）积累了大量的迁移，这些迁移在我的单元测试中开始消耗相当多的时间。我想重置基线并开始一系列新的迁移。我查看了South documentation，完成了通常的Google / Stackoverflow搜索（例如“django south（重置或删除或删除）迁移历史记录”）并且没有找到任何明显的内容。

我已经考虑过的一种方法是通过“删除”南方或“清除”历史记录来“重启”（例如清除数据库表，从迁移主管中删除迁移文件），然后重新运行，

./ manage.py schemamigration southtut --initial

所以，如果有人以前做过这个并且有一些提示/建议，我们将不胜感激。

Answer 1

如果您需要有选择地（仅针对一个应用）重置花费时间过长的迁移，this对我有效。

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

不要忘记通过在depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial"))文件中添加<app-dir>/migrations/0001_initial.py等行来手动恢复其他应用上的任何dependencies，作为迁移类中{{1}下方的第一个属性}}

根据this SO answer，您可以在其他环境中class Migration(SchemaMigration):。当然，如果您伪造删除或伪造./manage.py migrate <app-name> --fake --delete-ghost-migrations，您需要手动删除任何带有this等迁移的遗留数据库表。

更多核选项是实时部署服务器上的migrate zero，后跟[my] sqldump。然后在需要迁移的，完全填充的数据库的环境中管道转储到[my] sql中。我知道南亵渎，但为我工作。

Answer 2

编辑 - 我在下面添加评论，因为在＆gt;之前阅读它是很重要的。在@andybak
之后接受了答案

@Dominique：您对manage.py重置南方的建议很危险     如果有任何第三方应用程序使用，可能会破坏数据库     在项目的南方，正如下面的@thnee指出的那样。既然你的     答案有这么多的赞成我真的很感激，如果你可以编辑     它并至少添加一个警告，或者（甚至更好）改变它     反映@hobs方法（这同样方便，但没有     影响其他应用程序） - 谢谢！ - chrisv 2013年3月26日9:09


接受的答案如下：

首先，an answer by the South author：

只要您同时注意在所有部署中执行此操作，就不应该有任何问题。就个人而言，我会这样做：
    rm -r appname/migrations/ 
    ./manage.py reset south 
    ./manage.py convert_to_south appname 
（请注意，“reset south”部分会清除所有应用的迁移记录，因此请确保为所有应用运行其他两行或有选择地删除。

最后的convert_to_south调用会进行新的迁移并伪造它（因为您的数据库已经有相应的表）。在此过程中无需删除所有应用程序表。

当我需要摆脱所有这些不需要的开发迁移时，这就是我在dev + production服务器上所做的事情：

确保我们双方都有相同的数据库架构
删除双方的每个迁移文件夹
运行./manage.py重置南方（正如帖子所说）两侧=清除南方桌面*
双方运行./manage.py convert_to_south （伪造0001迁移）
然后我可以重新开始进行迁移并在我的服务器上推送迁移文件夹

*除非您只想清除其中一个应用程序，否则您需要编辑您的south_history表并仅删除有关您应用的条目。

Answer 3

感谢Dominique Guardiola和滚刀的回答，它帮助我解决了一个难题。但是解决方案存在一些问题，这是我的看法。

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

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

现在考虑升级到django-cms的最新版本，它将包含新的迁移，例如0009_do_something.py。当您尝试在迁移历史记录中没有0001到0008的情况下运行迁移时，南方肯定会感到困惑。

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

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

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

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

2。删除我的应用的迁移

$ rm -rf my_app/migrations/

3。为我的应用创建新的初始迁移

$ ./manage.py schemamigration --initial my_app

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

这会将迁移插入south_migrationhistory，而不会触及实际的表格：

$ ./manage.py migrate --fake my_app

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

Answer 4

就像thnee（请参阅她的回答）一样，我们对南方作者（Andrew Godwin）在其他地方引用的建议使用了一种更温和的方法，我们将我们对代码库的处理与我们对数据库的处理分开在部署期间，因为我们需要部署是可重复的：

我们在代码中做了什么：

# 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

部署代码后我们对数据库做了什么

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

Answer 5

如果您只是在开发机器上工作，我写了一个管理命令，它完全符合Dominique的建议。

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

与南方作者的建议相反，这不会影响其他使用南方安装的应用程序。

Answer 6

以下仅在您要重置所有应用时。请在工作之前备份您的所有数据库。如果有任何内容，请记下初始文件中的depends_on。

一次：

(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]

在推送之前测试引导您的项目。然后，对于每台本地/远程计算机，请应用以下内容：

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

您希望重新参与每个应用的初始（3）。请注意，reset（6）将仅删除迁移历史记录，因此对库无害。虚假迁移（7）将恢复安装的任何第三方应用程序的迁移历史记录。

Answer 7

从app文件夹中删除必要的文件

实例路径

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

wiki -is my app

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

7 个答案:

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

2。删除我的应用的迁移

3。为我的应用创建新的初始迁移

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