質問: **シナリオ:** 私は、私たちのソフトウェア製品(ネットワークベースのWebアプリケーション)の1つでEF6を使用しています。私たちは、顧客のマシンにインストールされた異なるバージョンの製品を持っています。すべての顧客はサポート期間がx月であるため、異なるバージョンの製品で実行されており、それぞれのデータベースは異なるEF移行上にあります。 私は、製品のサポートを手伝ってくれる他の同僚をいくつか抱えていて、製品のさまざまなバージョンの顧客からの電話サポートを定期的に処理しています。 **問題:** 製品はEFデータベースのアップグレードのみをサポートし、データの損失の懸念からダウングレードはサポートされていません。したがって、古いバージョンをサポートする必要があるときは、EFデータベースをアップ/ダウングレードするための内部ツールを使用します。問題は、私の同僚が、どのデータベースの移行がどのバージョンの製品と合っているかを認識していないことです。 だから私の質問:私たちの製品バージョンを移行履歴行に添付する方法はありますか? これまで私が考えてきたこと: 1. マイグレーションの名前に製品バージョンを埋め込みます。 これは可能ですが、マイグレーションに製品バージョンを確実に含めるために他の開発者を訓練する必要があります。 2. 製品のメジャーリリースごとに空のマイグレーションを作成します。 これは、アプローチ1と同じ問題を抱えています。これを製品リリーススクリプトに自動化することはできますが、それには多大な労力が必要です。 **私が望むもの:** 私は、移行自体を伴う製品バージョンを添付しようとしています。つまり、この情報を保持する`MigrationHistory`テーブルに新しい列を追加したい( `HistoryRow`から新しいクラスを`HistoryRow` )。 どのバージョンでデータベース移行テンプレートを傍受して製品バージョン(アセンブリバージョン)を移行に埋め込むことができないのか、わからないのですが、手動で行う必要はありません。 私はあなたのうちの1人がこの痛みを感じているに違いないと確信しています。おそらくもっと良い解決策があります。任意のアイデア/提案?
回答: HistoryContextのカスタムサブクラスを実装および登録することによって、Migrations Historyテーブルをカスタマイズできます 。次に、通常のDbContextのすべての傍受メソッド、SaveChanges、ValidateEntityなどがあります。 しかし、私はこれが本当に役立つとは思わない。 Migrationがいつ*適用される*かは、実際には気にしません。これは、HistoryContextがあなたに伝えるものです。あなたのリリースに関連して移行が*作成された*ときは気になります。 実際、あなたにはあなたにこれを伝えるものはありません。あなたは、あなたがそれを作るときに変更がどのようなリリースになるのかを知ることはできません。 あなたのアイデアは、「製品の主要なリリースごとに空の移行を作成する」と思います。正しいものです。その空の移行では、リリース名を格納するテーブルを更新するコードを追加できます。