9

同じ Django アプリであまりにも多くのモデルを作成するというばかげた間違いを犯したため、3 つの異なるモデルに分割したいと考えています。問題は、2 つの顧客のサイトで既に運用中のデータがあるため、実行するスキーマ/データの移行を慎重に計画する必要があることです (私は django-south を使用しています)。どのように進めたらよいかわからないので、アドバイスをいただければ幸いです。

（関係がある場合は、Ubuntuサーバー12.4 LTSでPostgreSQLを使用しています）

を使用することを考えましdb.rename_tableたが、外部キーをこれらのモデル (古いものから新しいものへ) に正しく更新する方法がわかりません - データベース レベルでは関係ありません (テーブルの名前変更は既にカバーされているため) が、ORM レベルではそうではありません.

更新: それについて考えた後、 programmmers.SE でこの質問をした後、物事をシンプルに保ち、製品のメジャー バージョン間の移行について心配しないことにしました。短期的には、モデルを古いアプリに保持しながら、ダニエル・ローズマンが提案したようにdb.rename_table使用しながら、新しい名前に一致させるために使用します。db_tableメジャー バージョンにアップグレードするときは、新しいアプリに切り替えて、すべての移行を完全に破棄します (そのため、新しいバージョンを新しくインストールすると、過去のすべての移行を行うのではなく、データベースが「そのまま」作成されます)。

4

3 に答える 3

15

なぜデータ移行が必要なのかまったくわかりません。

モデルを新しいアプリに移動db_tableし、古いテーブル名を指すように内部Metaクラスに設定を追加するだけです。

于 2012-07-16T17:31:35.417 に答える
3

最近、小規模で同様のことを行いましたが、これが私のプロセスでした:

  1. 新しいアプリと対応するモデルを作成する
  2. ビューを更新して新しいモデルを使用する
  3. ユニット/システム テストを更新して、何も壊れていないことを確認します (重要!)
  4. 古いモデルに基づいて新しいモデルを設定する管理コマンドを作成する
  5. コードをデプロイする
  6. 新しいモデルの移行を実行する
  7. 管理コマンド スクリプトを実行して新しいモデルを更新する
  8. 古いアプリを 1 ～ 2 週間放置し、問題がないと判断したら削除します。

データ移行を使用しなかった理由:

  1. 慣れていない -- 慣れていないプロセスを使用するにはタスクが重要すぎると感じた
  2. サウス マジックよりも Python コードを使用した方が快適にデータを移動できます
  3. 依存関係で南部への移行の問題が発生しました。データ移行で移行をさらに複雑にしたくありませんでした。データ移行の仕組みに慣れていないため、これは根拠のない仮定になる可能性があります
  4. おそらくポイント 3 からの偏見として、South を純粋にスキーマ管理ツールとして使用することが「正しい」方法であると確信しました。データの作成/更新は、フィクスチャまたはカスタム管理コマンドを使用して Django レイヤーで行う必要があります
于 2012-07-16T06:11:16.923 に答える
2

私が考えることができる最も簡単な解決策：

  1. SchemaMigration古いアプリのモデルへのすべての外部キーの型をプリミティブ型 (その内部のものを含む) に変更するを作成します。
  2. 新しいアプリとそのモデルを通常どおり作成します。
  3. 古いテーブルから新しいテーブルへのデータ移行を行います。
  4. 別の を作成しSchemaMigration、すべてのプリミティブ型を再び外部キーに変更して、新しいテーブルを指すようにします。
  5. 設定から古いアプリを削除し、そのテーブルを削除します。

はい、面倒ですが、うまくいきます。しかし、より良い解決策を願っています。

于 2012-07-16T04:36:45.830 に答える