我们有多个开发人员在使用Entity Framework 5.0的项目上工作.每个开发人员都使用自己的本地SQL 2012数据库,这样他就可以开发和测试而不会妨碍其他人.
起初,我们使用了自动迁移和基于代码的迁移的混合体.这根本不起作用,所以我们决定禁用自动迁移,只允许基于代码.我应该补充一点,我们再次启动了一个干净的数据库而没有_MigrationsHistory来自所有自动迁移的"损坏" .
所以现在的工作流程是:
add-migration <Name>将其应用于他的数据库update-database.到目前为止,这运作良好.然而,在今天之前,通常只有我做了迁移而其他人应用了它们.但今天有来自三个开发人员的迁移.我刚刚完成了这些迁移,做了一件update-database好事.
我也对自己的数据模型进行了更改,但是在结束时update-database它给了我一个警告,我仍然没有更新,所以我做了add-migration <my migration>.但是,当它支持迁移时,它给了我已经应用到数据库的所有迁移的更改.所以:它试图删除已经删除的列,尝试创建一个已经存在的表,等等.
怎么可能？我的假设是EF只是检查_MigrationsHistory表格并找出表格中没有的迁移,并按名称的时间戳顺序应用这些迁移.但显然不是,因为即使我撤消自己的更改并且我有一个干净的环境,它仍然抱怨我的数据库与模型不同步.但我只是将这些更改删除并应用到我的数据库中.它是同步的.我也可以看到我刚才在_MigrationsHistory表格中应用的迁移.
我唯一能想到的是我在一个不会导致数据库更改的数据模型中添加了一个属性(我List<X>在数据模型中添加了一个Y,其中X是一对多关系中的多个.这不会导致数据库更改,因为X已经有一个外键到Y).可能是吗？如果是这样,那真的很脆弱,因为没有办法为此添加迁移,因为没有数据库更改,我也不知道如何解决这个问题.
我不知道如何处理这个问题,因为我当然可以编辑它所支撑的内容并删除已经应用于我的数据库的所有内容.但那又怎样？我检查它然后其他一些开发人员得到相同的消息,即使他的数据库不适用于我的新更改,支持他自己的更改,获取相同的无意义脚手架,编辑它,检查它然后下一个开发者得到它.它变成了一个恶性循环,与我们使用自动迁移时的情况类似,我认为我们已经通过切换到基于代码的方式来解决这个问题.我现在不能相信做正确的事情,这样做是一场噩梦.
我也尝试过添加我从同事那里逐一删除的迁移,update-database -t:201211091112102_<migrationname>但无济于事.它仍然给我错误的脚手架.
那么我们在这里做错了什么,或者EF根本不是为这样的协作而构建的？
UPDATE
我创建了一个可重现的测试用例,虽然为了模拟这个多用户/多数据库场景,它有点冗长的舞蹈.
https://github.com/JulianR/EfMigrationsTest/
有上述项目时重现的步骤(这些步骤也出现在代码中):
以上是模拟三个用户,其中用户1进入他的数据库,另外两个用户也使用他的初始化来创建他们的数据库.然后,用户2和用户3都对数据模型进行自己的更改,并将其与应用更改所需的迁移一起添加到源控件.然后,用户1拉动用户2和3的更改,而用户1也自己对数据库进行了更改.然后,用户1调用update-database以应用用户2和3的更改.然后,他自己进行迁移,然后错误地将用户2或3的更改添加到脚手架迁移,这会在应用于用户1的数据库时导致错误.