web-dev-qa-db-ja.com

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

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

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

./manage.py schemamigration southtut --initial

だから、誰かがこれを以前にやったことがあり、いくつかのヒント/提案があれば、彼らは非常に感謝されます。

djangodjango-south
154
Glenn Snyder

編集-@andybakに続く>受け入れられる回答の前にそれを読むことが重要であるため、この上部に以下のコメントを入れています

@Dominique：manage.py reset southに関するアドバイスは危険です。プロジェクトでsouthを使用しているサードパーティアプリがある場合、データベースを破壊する可能性があります（以下の@thneeが指摘）。あなたの答えは非常に多くの賛成票を持っているので、あなたがそれを編集して少なくともこれに関する警告を追加するか、（さらに良い）@hobsアプローチを反映するように変更できれば本当に感謝します（同じように便利ですが、他のアプリに影響する）-ありがとう！ – chrisv 13年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. 両側で./manage.py reset southを実行します（投稿によると）=南のテーブルをクリアします*
  4. 両側で./manage.pyconvert_to_southを実行します（0001移行を偽装）
  5. その後、移行を再開してサーバー上の移行フォルダをプッシュできます

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

122
Dominique Guardiola

（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"))のような行を、class Migration(SchemaMigration):のすぐ下の移行クラスの最初の属性として<app-dir>/migrations/0001_initial.pyファイルに追加して、他のアプリの dependencies を手動で復元することを忘れないでください。

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

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

188
hobs

ドミニク・グアルディオラとホブの回答のおかげで、難しい問題を解決することができました。ただし、このソリューションにはいくつかの問題があります。ここに私の考えを示します。

manage.py reset southの使用はお勧めできません Southを使用するサードパーティアプリがある場合、たとえばDjango-cms（基本的にはすべてSouthを使用）です。

reset southは、インストールしたすべてのアプリのすべての移行履歴を削除します。

Django-cmsの最新バージョンにアップグレードすると、0009_do_something.pyなどの新しい移行が含まれることになります。移行履歴に0001から0008を含めずに移行を実行しようとすると、Southは確実に混乱します。

メンテナンス中のアプリのみを選択的にリセットする方がはるかに安全です。

まず、ディスク上の移行とデータベースで実行された移行との間でアプリの同期が解除されないようにしてください。そうしないと頭痛がします。

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の単なるより長い変形ですが、実稼働データベースの変更などの微妙な状況では、この追加の制御を好みます。

54
thnee

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
7
tobych

開発マシンで作業しているだけなら、ドミニクが提案したこととほぼ同じことを行う管理コマンドを書きました。

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

南の著者の提案とは対照的に、これは南を使用して他のインストール済みアプリを害することはありません。

1
idanzalz

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

インスタンスパス

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

wiki-私のアプリ

0
Andrei Eremchuk

以下は、すべてのアプリをリセットする場合のみです。その作業の前にすべてのデータベースをバックアップしてください。また、初期ファイルに 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）は、インストールされているサードパーティアプリの移行履歴を戻します。

0
placeohlder