Django Southを使用して移行履歴をリセットするための推奨アプローチは何ですか？

私は、South（0.7）とDjango（1.1.2）を使用してかなりの数のマイグレーションを蓄積してきました。これらは、ユニットテストでかなりの時間を消費し始めています。ベースラインをリセットして、新しい移行のセットを開始したいと思います。私はSouthのドキュメントを確認し、通常のGoogle / Stackoverflow検索を実行しました（たとえば、「django south（リセットまたは削除または削除）移行履歴」）。明らかなものは何も見つかりませんでした。

私が考えた1つのアプローチは、Southを手動で「削除」または「クリア」して「最初からやり直す」（たとえば、dbテーブルをクリアする、migrations directorから移行ファイルを削除する）ことと、単に再実行することです。

./manage.py schemamigration southtut --initial

したがって、誰かがこれを以前に行ったことがあり、いくつかのヒント/提案があれば、彼らは大いに感謝します。

編集-@andybakに続く>承認された回答の前にそれを読むことが重要であるため、これの上部にコメントを付けます

@Dominique：以下の@thneeで指摘されているように、manage.py reset southに関するアドバイスは危険であり、プロジェクトでsouthを使用しているサードパーティのアプリがある場合、データベースを破壊する可能性があります。あなたの回答には非常に多くの賛成票があるので、編集して少なくともこれに関する警告を追加できるか、@ hobsアプローチを反映するように（さらに良いことに）変更していただければ幸いです（これは同じくらい便利ですが、そうではありません）他のアプリに影響します）-ありがとうございます！– chrisv 2013年3月26日9:09

受け入れられた答えは以下の通りです：

まず、南部の作者による答え：

すべての展開で同時にそれを行うように注意する限り、これで問題は発生しないはずです。個人的に、私はやります：

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

（「reset south」の部分はすべてのアプリの移行レコードをクリアするため、すべてのアプリに対して他の2行を実行するか、選択的に削除してください）。

convert_to_south最後の呼び出しにより、新しい移行が行われ、それが偽で適用されます（データベースに対応するテーブルが既にあるため）。プロセス中にすべてのアプリテーブルを削除する必要はありません。

これらの不要な開発者の移行をすべて取り除く必要があるときに、開発者+本番サーバーで私がやっていることは次のとおりです。

1. 両側に同じDBスキーマがあることを確認してください
2. 両側のすべてのマイグレーションフォルダを削除する
3. run ./manage.py reset the south（post）両側で=南テーブルをクリア*
4. 両側で./manage.py convert_to_southを実行します（0001の移行に似ています）
5. その後、移行を再開してサーバーに移行フォルダをプッシュすることができます

* 1つのアプリのみをクリーンアップする場合を除き、そうする場合は、south_historyテーブルを編集して、アプリに関するエントリのみを削除する必要があります。

あなたが選択する必要がある場合は時間がかかりすぎているリセットマイグレーション（ただ1つのアプリのために）、これは私のために働きました。

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ちょうど下のマイグレーションクラスで最初の属性として、ファイルclass Migration(SchemaMigration):。

その後./manage.py migrate <app-name> --fake --delete-ghost-migrations、このSOの回答に従って、他の環境で行うことができます。もちろん、削除を偽造したり、偽造したりするmigrate zero場合は、このような移行で残っているdbテーブルを手動で削除する必要があります。

より核となるオプションは./manage.py migrate --fake --delete-ghost-migrations、ライブ展開サーバーで[my] sqldumpを実行することです。次に、そのダンプを、完全に移植された移行済みのdbが必要な環境の[my] sqlにパイプします。南の聖職者、私は知っているが、私のために働いた。

Dominique Guardiolaとhobsの回答のおかげで、難しい問題の解決に役立ちました。しかし、解決策にはいくつかの問題があります。これが私の見解です。

たとえば、Southを使用するサードパーティのアプリがある場合（基本的にはすべてSouthを使用する）、使用manage.py reset 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が、実稼働データベースの変更などのデリケートな状況では、追加の制御を優先します。

thnee（彼女の回答を参照）のように、ここでは他の場所で引用されているSouthの作者（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

開発マシンで作業しているだけの場合は、Dominiqueの提案とほぼ同じことを行う管理コマンドを作成しました。

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

南部の作者の提案とは対照的に、これは南部を使用してインストールされている他のアプリを害しません。

以下は、すべてのアプリをリセットする場合のみです。その作業の前に、すべてのデータベースをバックアップしてください。また、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）を実行します。リセット（6）はマイグレーション履歴のみを削除するため、ライブラリに害はないことに注意してください。偽の移行（7）は、インストールされているすべてのサードパーティアプリの移行履歴を元に戻します。

アプリフォルダーから必要なファイルを削除する

インスタンスパス

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

wiki-私のアプリです