4

非常に簡単に：

LadislavMrnkaの記事に基づいてCodeFirstとして構築された既存のプロジェクトにEFMigrationsを実装していました

すでに本番環境に移行しているプロジェクトにEF移行を実装する場合、開発に適用された更新と本番環境用に生成されたスクリプトの間で移行スクリプトをどのように管理できますか？

私が困惑している理由は、スクリプトごとに生成されたMigrationIdにTimeStampが追加されているためです。移行の試みで、devとprodの__MigrationHistoryテーブル内に記録されたエントリが異なることに気付きました。したがって、DBがかなりの数の移行アップグレードを実行する場合、何らかの理由でダウングレードが必要になった場合は、疑問が生じます。 、を使用してスクリプトを作成するための正確なMigrationIdを相互に関連付けることは非常に困難です。update-database -script

テーブルを作成する$InitialMigrationを作成する非常に簡単なプロセス。__MigrationHistory次に、モデルへの変更の後update-databaseに、データベースを移行するための変更が続きます。そして、このプロセスは、モデル変更の論理的にグループ化されたバッチがある場合は常に循環します。

__MigrationHistory表を見ると、

+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
|            MigrationId             |        CreatedOn        |                              Model                               | ProductVersion |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
| 000000000000000_BootstrapMigration | 2012-03-01 17:40:39.567 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...CA7F54A20F50000 | 4.3.1          |
| 201203011745335_AutomaticMigration | 2012-03-01 17:45:33.557 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...F4AE3681EF50000 | 4.3.1          |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
4

1 に答える 1

3

あなたのコメントによると、解決策は簡単なようです。同じタイムスタンプを使用する場合は、1回だけ使用する必要がありUpdate-Databaseます。この場合は、次を使用することを意味します。

Update-Database -Script

作成したスクリプトを両方のデータベースで実行します。

とにかく、ダウングレードが予想されるシナリオでは、おそらく自動移行を使用しないでしょう。すべての移行に明示的な名前のコードベースの移行を使用します。このような場合、テーブル内のすべてのレコードにMigrationHistory一意の名前を付ける必要があり、タイムスタンプは重要ではありません。

于 2012-03-06T11:35:59.110 に答える