1

私は EF Migrations を読んでいて、それをいじり始めています。

私はソース管理に Git を使用しており、新機能の作業を開始するたびにブランチを作成しています。その理由は、別の機能にすばやく移動する必要がある場合、またはプッシュする必要がある重要なバグ修正を行う必要がある場合、ブランチを変更して作業を続行できるからです。

現在、実稼働環境 (web.config appsetting) にいない場合、データ モデルの変更があった場合 (コード ファースト) にデータベースを再設定するようにアプリをセットアップしています。わずかなモデルの変更でデータを完全に破壊する必要がないという点で、移行は良いと思いました。

残念ながら、私が望んでいたほどバージョン管理に適していないという兆候がいくつか見られます。たとえば、データ モデルに新しい列を追加し、データベースを更新してから、変更を元に戻すことにした場合、EF はモデルの変更をデータベース自体に格納するため、引き続きモデルの変更を認識します。

ブランチが最初に発生したときにdbバージョンをダウングレードし、多くの記憶と手動追跡なしで作業することにしたブランチ上のdbがある場所に移行するように指示する明確な方法はないようです。

バージョン管理を伴う重要な開発シナリオで移行を利用する方法についての戦略を持っている人はいますか?

4

1 に答える 1

3

各ブランチには、他のブランチが明らかに知ることができない移行が含まれるため、データベースを一致するように変換する方法を知る方法はありません（自動移行を使用しないと、とにかくうまくいくとは思えません）。

さまざまなブランチをサポートするための最善の戦略は、話しているブランチの数に応じて、それぞれがデータベースの独自のコピーをターゲットにすることです。そうすれば、自由に好きなだけそれらの間をジャンプでき、変更が加えられたりマージされたりしたときにのみ、それらは自分のデータベースにアクセスします。

または、コアデータが移行スクリプトの一部であることを確認し、現在のようにデータベースを吹き飛ばします。

編集：ブランチ間で変更をマージした後、add-migrationコマンドを使用してメタデータを再生成する必要がある場合があります。

于 2012-03-17T08:41:43.273 に答える