update.この記事についてDjangoのマイグレーション関連の情報を自分なりに整理しました。バージョンは1.11です。データベースマイグレーションとはアプリケーションで使うデータベースの定義を自動的に作成・管理する機能です。旧来データベースに接続して直接変更を行っていた作業を、モデルから自動生成されるコードの実行で置き換えます。・定義変更用のSQLを作成する手間がなくなる。・データベースがバージョン管理されるので複数人での開発作業がやりやすくなるといったメリットがあり、過去の手法に比べ作業効率が大幅に上がります。Djangoでは1.7以降のバージョンで標準的に利用できます。同様の機能は他のフレームワークにも存在します。日本語の文献は他のフレームワークの方が多いです。基本的な考え方や用語は一緒なので、探して読むと参考になります。基本用語モデルmodel.py内のクラス定義。具体的にはDjangoで管理したいデータ(ブログ、注文など)のデータ設計。model.pyの射影をデータベースに作成するのがデータベースマイグレーションの目的です。マイグレーションファイルmodel.pyの内容をデータベースに反映させるための中間ファイル。makemigrationsコマンドで作成する。初回のデータと、それにつらなる一連の差分データで構成されます。処理の内容が記述されます。マイグレーションディレクトリアプリケーションのディレクトリにあるmigrationsディレクトリ。makemigrationsを実行すると、マイグレーションファイルが連番付でここに出力される。最初の実行で実行時点のmodel.py全体の内容が出力され、次の実行からはmodel.pyの変更分が別ファイルとして出力される。マイグレーション実行または「マイグレートする」といわれる。マイグレーションファイルの内容をSQLに翻訳しデータベースに適用する。基本的には最新の状態まで適用するが、データベース定義を特定の状態まで進めたり戻したりもできる。ロールバック過去のマイグレーションIDを指定してマイグレーションを実行すると、そのIDの適用前の状態まで適用が取り消される。これをロールバックするという。マイグレーション管理テーブル初回マイグレーション実行時、データベースには「django_migrations」というテーブルが作成され、どこまでマイグレーションファイルを適用したかを管理する。showmigrationsで表示される[X]のマークはこのテーブルの内容と照合させて表示している。To複数世代のマイグレーションをマージする単純に一つのファイルにまとめる。適用後は元ファイルの削除を勧告される。--merge一つのマイグレーションファイルから複数のマイグレーションファイルが分岐してしまった状態を修復するこのコマンド。基本的にマイグレーションファイルは直列関係になっていなくてはならないが、チームでの開発だと容易に並列箇所が生まれる。分岐した複数のマイグレーションファイル全てをdependenciesに持つ、空のマイグレーションファイルを作成し、分岐した流れを統合する。--empty空のマイグレーションファイルを作成する。operationsに処理を追加して使う。特殊作業の例マイグレーションファイルを作り直す適用済みのものがあるならロールバックを行い、やり直したい期間のマイグレーションファイルを削除してmakemigrationsを再実行する。マイグレーションファイルの作成前までソースコードをロールバックする必ず先にマイグレーションのロールバックを行い、そののちソースコードをロールバックする。※Migrationファイルがなくなるとソースコードのロールバックが実行できなくなるため。squashmigrationsでマイグレーションファイルをまとめられる。特定時点から最新状態までをまとめるなら、特定時点までのファイルを削除してmakemigrationsを再実行してもいい。マイグレーションが失敗する場合は。使いどころマイグレーション機能は万能というわけではないので、エラー回避のためどうしても直接データベースを変更するケースが出てくる。以下はユニークキーの追加でマイグレーションが使えなかったケースである。ユニーク制約付きのカラムを追加するときの注意点そのような場合は1。--fake」を実行してマイグレーションが無事終了したように記録する。ソース管理の観点より、作業内容をマイグレーションファイルのコメントとして追記しておく。TIPSマイグレーションディレクトリに余計なファイルがあるとエラーになる。中間のファイルを一つでも損失するとディレクトリにあるデータ全体が不正なものになるので、うっかり削除しないように注意する。マイグレーションファイルの名前(モジュール名)はそのままIDとなり、django_migrationsテーブルやdependenciesで使われる。マイグレーションファイルには自動的に連番が付くが番号は適応順と関係ない。適応順はdependenciesを評価して決まる。組み込みアプリにもマイグレーションファイルは存在する。確認したいときは以下のディレクトリを参照。null制約がデフォルトで指定される。null制約があるフィールドを追加すると、migrate時に既存レコードに対しての処理をいちいち確認されてなかなか面倒くさい。null制約を付けた方がストレスがたまらない。マイグレーションはロールバックができるが、マイグレーションファイル破棄前に実行するのを忘れて結局ロールバックできなかったりする。開発環境ではスキーマの全オブジェクト削除をすぐ実行できるようにしておいて、最初から構築しなおした方が楽かも。dumpdataとloaddataやデータベースの直接更新を取り合わせて使い、臨機応変に対応しよう。requestStockLike161@okoppe8札幌でシステムエンジニアをしています。「Djangoで業務システム作る時に必要な機能をあらかじめ用意する」というテーマでやってます。upLoginユーザーは見つかりませんでした。