【T7a】データモデルの変更とマイグレーションの設計(7/7)
プロジェクトタイプ | (注意: 本文参照) |
---|---|
プロジェクト名 | T7a |
ソリューション名 | PIT7 |
注意
- 本ページの作業内容は 前のページまでの続き になっていることに注意せよ.
- 先に前のページまでをすべて読み,指示されている作業を済ませてから本ページを読むこと.
- プロジェクトの作成作業については準備作業を参照せよ.
7a-7. プログラム試作中におけるマイグレーション処理の要否
最後に,プログラム試作中のマイグレーション処理の必要性について説明しておこう. 本コースでは後半にウェブアプリの自由製作を予定しているが, 自由製作のほとんどの場面はいうまでもなく「プログラム試作中」となるため以下の説明は非常に重要である. よく読んで理解しておこう.
ここまでに説明したデータベースマイグレーションの管理は, 基本的にデータベース側に維持したいデータが存在しているとき に必要となるものである. 「維持したいデータが存在しているとき」とは,たとえばそのウェブアプリがサービスイン後であり利用者が登録したデータが既に存在している場合などである1.
逆にデータベースの内容を壊してよいのであれば,わざわざ手間をかけてマイグレーション処理を作成する必要性は皆無である .
たとえばそのプログラムが試作中であり,モデルクラスの定義がまだ固まっていないときには無理にマイグレーション処理を作成する必要はない.
そのような場合は pgAdmin でそのデータベースを削除(ドロップ)し(_),プロジェクト内の Migrations フォルダを丸ごと削除して(_),
dotnet ef migrations add
/ dotnet ef database update
コマンドを実行しなおせばよい(_,_).
ここまでを理解したらひとつ目のチュートリアルは完了である. 次に進む前に,混乱を防ぐため Visual Studio のエディタをすべて閉じておこう.Visual Studio のいずれかのエディタのタブを右クリックして 「すべててのドキュメントを閉じる」をクリックすれば,エディタをすべて閉じることができる .
内容的にクリティカルなサービスでない場合は,サービス更改時にデータベースを全削除(いわゆる DB爆破 )をしてしまうような乱暴な運用をすることもなくはないが,商用サービスでは言うまでもなく避けるべきである(参考: 「mstdn.jp」サーバ移転完了 データは全消去、再度ユーザー登録を - ITmedia NEWS). ↩︎