Southを使い始めたばかりで、100%売れています。また、まだ非常に活発に開発されている数少ないものの1つです。
サウスは、上記で説明した問題を適切に処理できるはずです。dbを変更するたびに、「foward」と「backwards」の2つのメソッドを持つファイルが作成されます。自動生成された移行のサンプルは次のとおりです。
# > manage.py schemamigration issuetracker added-status-field --auto
# 0004_added-status-field.py
class Migration:
def forwards(self, orm):
# Adding field 'Issue.status'
db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])
def backwards(self, orm):
# Deleting field 'Issue.status'
db.delete_column('issuetracker_issue', 'status')
それについてのいくつかの素晴らしいこと....
Southでは、必要に応じて特定の移行にロールバックできます。
本番サイトが移行0002にあり、SVNコミットが0004にある場合、Southは0003、次に0004を実行して、本番データベースを高速化します。
先に進んで自分で変更を加えた場合は、「偽の」移行を実行するようにSouthに指示できます。通常、移行システムはヒッシーフィットをスローしますが、これにより、データベースを柔軟に制御することが非常に簡単になります。
manage.py migrate [appname] --fake
ある列のデータを別の列にコピーするなど、何かカスタムを行う必要がある場合、移行ファイルは単なるPythonファイルであるため、順方向/逆方向の関数を簡単に変更できます。
アプリケーションをすでにデプロイした後、南に移行するのはかなり簡単でした。最新バージョン0.6には、実際にそのためのコマンドが含まれています。
manage.py convert_ to _south [appname]
そしてもちろん、どうして忘れることができますか?私のお気に入りの機能は移行ファイルの自動生成です
manage.py schemamigration [appname] [description] --auto
ガッチャ
サウスを始めたときに犯した間違いのヒントをいくつか追加する必要があると思いました。すべてが100%直感的であるとは限りません。
開発データベースでconvert_to_southコマンドを実行した後、本番データベースで実行することを忘れないmigrate --fake
でください。そうしないと、Southはそれが古くなっていると見なします。
新しいアプリを作成する場合は、--initial
フラグを使用します
manage.pysyncdbの使用を停止します。本当に。
モデルの編集は3ステップのプロセスです-
1.)モデルの変更を保存します
2.)実行schemamigration --auto
3.)migrate
データベースへの変更を実際にコミットするために実行します
編集- 以下のコメントを明確にするために、Southは、バージョン1.2に含まれないようにコアコントリビューターによって公式に投票されました。これは、サウスの作者がまだ含まれていないことを要求したためです。それでも、Southには多くのコミュニティサポートがあり、一部の再利用可能なアプリメーカーは、アプリにSouthの移行を含め始めています。
編集#2-現在のトランクバージョンのSouthからの新しいmanage.pyコマンド構造を反映するようにいくつかの更新を行いました。「startmigration」は、実行内容に応じて「schemamigration」と「datamigration」に分割されています。