为什么Entity Framework的EF迁移添加迁移步骤需要数据库连接字符串？

Question

为什么Entity Framework的EF迁移添加迁移步骤需要数据库连接字符串？

Sco*_*ord 24 entity-framework-4 ef-migrations entity-framework-4.3

我正在尝试使用和理解EF迁移(使用EF 4.3.1,Code First).为了支持一个新的变化,我必须使用这样的命令:

Add-Migration MyMigration
   -ConnectionString "Data Source=.;Initial Catalog=mydb;" 
   -ConnectionProviderName "System.Data.SqlClient"
   -StartUpProjectName MyWebsite 
   -ProjectName MyEF.Migrations

Run Code Online (Sandbox Code Playgroud)

为什么Add-Migration需要连接字符串数据？ Update-Database需要一个,这是有道理的.但是,Add-Migration是否具有DbContext和Configuration所需的一切？

这不仅仅是空闲的奇迹,给它一个数据库是非常困惑的,因为我们有一个"多租户"的东西,所需的数据库是灵活的,可能会从请求变为请求,更不用说在静态编译时.因此,如果Add-Migration实际上正在使用该数据库,我们就会遇到问题.

更新:我们放弃了EF迁移并改为使用Fluent Migrator,并且很高兴.它更快,更快,甚至计算我们必须写两次事物(一次用于EF对象,一次用于迁移),并且它没有在这个问题中讨论的问题.

Answer 1

Lad*_*nka 12

Add-Migration检查数据库是否存在并与__MigrationHistory表进行交互.正如@Anders Abel所提到的,它用于调查待定迁移以及选择以前的模型以实际查找已更改的内容 - 如果您将显式迁移添加到启用了自动迁移的解决方案中,这一点尤为重要.

而且我不希望它知道挂起的迁移,因为它们特定于一个随机数据库碰巧所处的状态(并且与我或我的团队使用的其他数据不同)...;(我害怕我我越来越对EF Migrations的设计感到失望 - 似乎它试图做太多. (6认同)
你有多少数据库并不重要.在开发中,每个开发人员都应使用一个并准备基于代码的迁移.在部署期间,您应该将所有数据库移动到相同的状态.处理团队开发中的迁移非常棘手,如果两个开发人员同时对模型进行了更改,则需要通过一些手动合并来尽快提交模型更改和迁移.移民充满了国家 - 他们为发展带来了新的挑战.如果您不喜欢它,请不要使用它们并手动处理db update. (5认同)
我发布了一个类似的问题......基于代码的迁移要求数据库存在或保持最新是没有意义的！:( http://stackoverflow.com/questions/11204900/how-can-i-stop-add-migration-checking-my-database-has-no-pending-migrations-when (2认同)

Answer 2

And*_*bel 9

我在阅读你的问题时很好奇,所以我启动了一个Sql Server Profiler来查看运行add-migration时发生了什么.它确实连接到数据库并访问数据库以检查__MigrationHistory表.

尝试在不运行第一个的情况下创建第二个基于代码的迁移时产生的错误消息也显示了这一点:

由于以下显式迁移未决,因此无法生成显式迁移:[201205291928386_foo].在尝试生成新的显式迁移之前应用挂起的显式迁移.

我认为迁移引擎使用数据库中的序列化模型来计算新迁移中应包含的迁移步骤.

据我所知,数据库仅用作代码生成的帮助程序.只要您使用的所有各种数据库都与代码中的模型兼容,这对您来说应该不是问题.

编辑

正如@Ladislav Mrnka指出的那样,如果混合基于代码和自动迁移,则需要检查数据库.当您构建新迁移时,它应该包括自上次迁移以来模型中已更改的所有内容.如果您正在使用自动迁移,则不会在代码中跟踪这些迁移.在计算要在迁移中包含的更改时,上次运行迁移将用作基础.检查它的唯一方法是数据库 - 因为可能会启用自动迁移.

如果您只运行基于代码的迁移(我认为这是保持控制的唯一选择),那么该数据库可以被视为代码生成帮助.只要在您连接的所有数据库中确保了模型兼容性,一切都应该有效.

归档时间：	13 年，11 月前
查看次数：	22737 次
最近记录：	10 年，5 月前