EFコードファーストを独学しようとしていて、最初のデータベース作成セットアップを今のところ希望どおりに拡張し、データベースの最初の作成を進めていますが、データベースの将来の更新を処理および管理するための最良の方法を見つけようとしています。新しいデータベースの作成に取り組みます。
オンラインで良い例や提案が見つからないというシナリオを思いつきました。その時点でのコード内の POCO オブジェクトに基づいて、既存のモデルに基づいて新しいデータベースを作成する、ユーザーが新しいデータベースを作成できるアプリケーションが必要です。私が言ったように、それは今のところ私にとってはうまくいきます。少し後に、プログラムの更新が行われ、アセンブリ内の移行オブジェクトを介して何をすべきかがわかり、DbMigrator.Update() メソッドを使用して EF Code First 移行を使用してデータベースを更新します。これまでのところ、少なくともプログラムの初期バージョンについては順調です。
さて、後で、新しいバージョンで、何らかの理由で新しいデータベースを作成したいと考えています。したがって、それらはその時点でのコードの現在のモデルに基づいており、それはうまく機能します。ただし、アセンブリ内のその時点より前に、まったく実行する必要のないこれらの他の移行があります。モデルには、セットアップと準備が必要な可能性のある変更が既に含まれているためですが、新しく作成された移行テーブルはありません。少なくとも私が知る限り、そうではないことを知っています。それらを実行したくありませんが、将来の更新が後で必要になるデータベースに適用されるようにしたいと考えています。
私の考えでは、これまで読んだことから、最新の DB 移行がコード内にあるものを追跡する追加のロジックを作成する必要があるということです (さまざまな移行のある種のタイムスタンプ プロパティを使用して順序を決定します)。その日付/バージョンより前に存在する移行更新を実際には行わないように指示しますが、EF 移行ロジックは、特定の移行が実行されたことを示す情報で __MigrationHistory テーブルを更新します。リフレクションを介して手動でこれを実行して、移行オブジェクトを取得し、移行オブジェクト名を update メソッドに指定して順番に実行することを考えていますが、初期化中にデータベースの変更が実際に実行されないようにチェックします。その後、コードの更新後に新しいものがポップアップすると、古い移行は行われません。
その論理を理解するのに多くの時間を費やす前に、私が完全に見落としていた、または見逃していたドキュメントやパイプに何かがないことを確認したいと思いました。このケースを処理する最善の方法。私の意見では、これはかなり一般的なシナリオのように思えますが、基本的な EF ロジックでそれを処理する適切な方法がわかりません。