バックグラウンド：
私はEntity Framework Code Firstでアプリケーションを開発しており、POCOモデルを使用してデータベーススキーマをできる限り記述しています。ただし、移行 API だけが必要なもの (インデックスの追加など) をサポートする場合がいくつかあります。後で移行の追加を開始したくありませんでした。この時点でデータベースを再作成する方がはるかに高速ですが、それが唯一のオプションのように思えました。
それで、移行が機能するかどうかを確認できるかどうかを確認したいと思いました。最終的にはそれらを使用する予定でしたが、実際の移行を行う時が来るまで、初期移行を調整したり、再生成したりできることを望んでいました。しかし、私はこのアプローチにも本当に運がありませんでした。エンティティ フレームワークのコード移行には、移行の一部としてスキーマを強制的に格納 (シリアル化) するという点で根本的な欠陥があるようです。
私にとっては、プロパティを更新する方法がなかったため、移行を調整する方法がないことを意味していましたTarget(これは本質的に私のモデルのシリアル化されたバージョンです)。インデックスを個別に表現する方法がないため、移行を再生成することもできません。問題の 1 つは、移行の仕組みによって移行が連続的に行われることです。これは、過去の移行を更新したい場合や複数の開発者がいる場合にひどいことです。
したがってcontext.Database.ExecuteSqlCommand、インデックスを追加するために使用することを選択しましたが、移行のこの制限が将来変更されるかどうか、またはそれを回避できるかどうかを把握したいと考えています。
質問：
既存の移行を更新する方法はありますか? また、現場IMigrationMetadataで見つかったメタデータを必要としない移行を行う方法はありますか?Target