この質問のようdumpdataに、データベース用にベースのバックアップ システムをセットアップしました。dumpdataセットアップは、バックアップを呼び出してリモート サーバーに移動するcron スクリプトの実行に似ており、単純に使用loaddataしてデータベースを回復することを目的としています。ただし、これが migrations でうまく機能するかどうかはわかりません。削除されたモデル/フィールドを処理loaddataするスイッチが追加されましたが、列が 1 回限りのデフォルトで追加された場合やコードを適用した場合を解決することはできません。ignorenonexistentRunPython
私の見方では、対処すべき副次的な問題が 2 つあります。
dumpdata各出力ファイルに各アプリの現在のバージョンのタグを付ける- フィクスチャを移行パスにスプライスします
大量のオーバーヘッドを導入せずに最初の問題に取り組む方法について、私は困惑しています。{app_name: migration_number}マッピングを含むバックアップごとに余分なファイルを保存するだけで十分でしょうか?
プロセスは大まかに次のとおりであるため、最初の問題が解決されると、2番目の問題はより簡単になると思います。
- 新しいデータベースを作成する
- 各アプリの適切なポイントまで移行を実行します
loaddata指定されたフィクスチャ ファイルで呼び出す- 残りの移行を実行します
この質問には、この目的に適合できると思われるコードがいくつかあります(バグレポートからリンクされています)。
これらはデータベースのかなり定期的/大規模なスナップショットであるため、データの移行によって移行ディレクトリが乱雑になるため、それらを保持したくありません。