0

私のスキーマは、何度も繰り返して進化してきました。スキーマを空のデータベースから数十のテーブルと多数の列を持つデータベースに移行する一連の移行があります。

その過程で、テーブル、列、および制約がいくつか追加され、(経験や新しい知識、または仕様の変更に照らして) 削除または変更が行われることもあります。テーブルまたは列の名前が再利用または転用されている場合があります。

現在、EF 移行は、最新のスキーマに到達するために、作成、変更、ドロップ、再作成、変更などのシーケンスを完全に実行できるように見えますが、それは間違っているように感じます。極端なケースでは、テーブルを作成する数十の移行に続いて、最終的なスキーマが 1 つまたは 2 つのテーブルになるまで、さらに数十のテーブルを削除する可能性があります (可能性は低いと思います)。ゼロからファイナル テーブルに進むという選択肢は、適切に感じられるでしょう。

Ruby で ActiveRecord の移行を行っていた時代には、ステップスルーしたり、途中で作業を元に戻したりやり直したりすることなく、最終的なスキーマのみを構築するオプションがありました。もちろん、これは、移行のたびにスキーマの完全な DDL バージョンを最新の状態に保つことを意味していましたが、どういうわけかより洗練されているように感じました。

Entity Frameworkで似たようなことをした人はいますか?

4

2 に答える 2

0

次に、スクリプトを作成するための PM コマンドをここから始めます

EF 5 Code First Migrations から完全な SQL スクリプトを生成する

コードから、DbContext に直接ではなく、ObjectContext にオプションがあります。

 string script = (context as IObjectContextAdapter).ObjectContext.CreateDatabaseScript();

もちろん、魔法を見る必要がなく、生成されたスクリプトを変更している場合は、自動移行が機能します。

   Database.SetInitializer(new MigrateDatabaseToLatestVersion<YourDbContext,
                           YourMigrationConfiguration>()
   Context.Database.Initialize(true);

また、EmptyDb スキーマの場合、EF はそれを無料で行います。

  Context.Database.Initialize(true);
于 2013-04-25T14:58:15.783 に答える
0

__MigrationHistoryデータベースからテーブルを削除し、Migrationsフォルダーを削除 (Configuration.cs ファイルをバックアップ) してから、移行を再度有効にしてみてください。

于 2013-04-25T10:46:30.207 に答える