开发和生产

Question

非常简要地之间管理EF的Code First迁移：通过Ladislav Mrnka

当实现在EF迁移

我是基于文章建成的Code First现有项目实施EF迁移项目已投入生产，如何在应用于开发的更新和为生产生成的脚本之间管理迁移脚本？

我感到困惑的原因是，为每个脚本生成的MigrationId都附加了TimeStamp。在我的迁移尝试中，我注意到在dev和prod的__MigrationHistory表中记录的条目是不同的，因此引发了一个问题，如果数据库要经历不少迁移升级，那么如果因任何原因需要降级，这将是非常困难的合作涉及的具体MigrationId使用update-database -script

---

非常简单的过程，你创建一个用于创建__MigrationHistory表中$InitialMigration创建脚本。然后，对模型所做的任何更改都会被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   | 
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+ 

Answer 1

根据您的评论它看起来像解决方案是直线前进。如果你想有相同的时间戳必须使用Update-Database只有一次，在你的情况下，它意味着使用：

Update-Database -Script 

和执行创建的脚本在这两个数据库。

无论如何，我可能不会在预期降级的场景中使用自动迁移。对于每次迁移，我都会使用带有明确名称的基于代码的迁移。在这种情况下MigrationHistory表中的每个记录都应该具有唯一的名称和时间戳应该没有关系。