迁移实体框架在协作环境 [英] Migrations in Entity Framework in a collaborative environment

问题描述

我们有多个开发人员使用实体框架5.0的一个项目工作。每个开发者使用自己的本地SQL数据库2012这样他就可以开发和测试不妨碍他人。

We have multiple developers working on a project that uses Entity Framework 5.0. Every developer uses his own local SQL 2012 database so he can develop and test without impeding others.

首先，我们使用了自动迁移和code为基础的移民的混合体。这根本没有，因此我们决定禁用自动迁移和code为基础，以只允许很好地工作。我要补充一点，我们又开始用干净的数据库没有破坏 _MigrationsHistory 从所有的自动迁移。

At first, we used a hybrid of automatic migrations and code-based migrations. That didn't work well at all so we decided to disable automatic migrations and to only allow code-based. I should add that we started again with a clean database without a 'corrupted' _MigrationsHistory from all the automatic migrations.

所以，现在的工作流程是：

So now the workflow is:

1. 开发者改变了数据模型


2. 确实添加迁移＆LT;名称＆gt; ，并将其与适用于他的数据库更新数据库
   
3. 在数据模型的变化检查并迁移到Git的。


4. 另一个开发商拉，接收更改，并将其应用于自己的数据库中。

1. Developer changes his datamodel
2. Does add-migration <Name> and applies it to his database with update-database.
3. Checks in the datamodel change and the migration into Git.
4. Another developer pulls, receives the changes and applies it to his database.

到目前为止，运作良好。然而，它是今天之前通常只是我谁做的迁移和其他应用它们。但今天有来自三个开发迁移。我刚拔掉那些迁移，做了一个更新数据库哪去了罚款。

So far, this worked well. However before today it was usually just me who made the migrations and the others applied them. But today there were migrations from three developers. I just pulled those migrations, did an update-database which went fine.

我也有一个改变我自己的数据模型然而这样的更新数据库的结尾它给了我一个警告，我仍然不是最新的，以便我做了添加迁移＆LT;我的移民＆GT; 。然而，当它脚手架迁移，它给了我，我已经应用到数据库中的所有迁移的变化。所以：它试图丢弃已经降到列，试图创建一个已经存在的表等。

I also had a change to my own datamodel however so at the end of the update-database it gave me a warning that I still wasn't up to date so I did add-migration <my migration>. However when it scaffolded the migration, it gave me the changes of all the migrations I had already applied to the database. So: it tried to drop columns that had already been dropped, tried to create a table that already existed, etc.

怎么可能呢？我的假设是，EF只会检查 _MigrationsHistory 表，并找出哪些是迁移表中没有present但并应用这些一个接一个的时间戳有序这是名称的一部分。但显然不是，因为即使当我解开我自己的变化，我有一个清洁的环境仍然抱怨我的数据库是不是在与模型同步。但我只是拉着这些变化，并将它们应用到我的数据库。它的是的同步。我可以看到，我只是在 _MigrationsHistory 表应用于太迁移。

How can that be? My assumption was that EF would just check the _MigrationsHistory table and find out which migrations weren't present in the table yet and apply those one by one ordered by the timestamp that's part of the name. But apparently not, because even when I undo my own changes and I have a clean environment it still complains my database isn't in sync with the model. But I just pulled those changes and applied them to my database. It is in sync. I can see the migrations that I just applied in the _MigrationsHistory table too.

我能想到的唯一的事情是，我添加了一个属性，不会导致数据库的变化（我添加了一个列表℃的数据模型; X＆GT; 来数据模型Y其中X是在所述一对多关系的许多，这将不会导致在数据库中变更为X已经有一个外键为Y）。莫非是吗？如果是这样，那真的很脆弱，因为没有办法添加该迁移，因为没有数据库的变化，我不知道如何可以解决这个问题。

The only thing I can think of is that I added a property to a datamodel that wouldn't result in a database change (I added a List<X> to datamodel Y where X is the many in the one-to-many relationship. This wouldn't result in a database change as X already had a foreign key to Y). Could that be it? If so, that's really fragile because there's no way to add a migration for that since there's no database change and I'm not sure how to fix this either.

我不知道如何解决这个问题，因为我当然可以只需编辑什么脚手架，并删除已应用到我的数据库的一切。但是然后呢？我检查它，然后一些其他开发人员获取他的数据库是不是最新的，甚至我的应用新的变化后，相同的消息，脚手架他自己的变化，得到了相同的废话脚手架，编辑它，检查它，然后在接下来的开发商得到它。它成为一个恶性循环，类似的一个，当我们使用自动迁移，我认为通过切换到code仅基于我们已经定了我们了。我不能相信它现在做正确的事情，这是一起工作这样的噩梦。

I'm not sure how to deal with this, because I can of course just edit what it scaffolded and remove everything that has already been applied to my database. But then what? I check it in and then some other developer gets the same message that his database isn't up to date even after applying my new changes, scaffolds his own changes, gets the same nonsense scaffolding, edits it, checks it in and then the next developer gets it. It becomes a vicious circle and a similar one to what we had when we used automatic migrations and I thought we had fixed that by switching to code-based only. I can't trust it right now to do the right thing and it's a nightmare to work with like this.

我也试过从我的同事一个一个加入我把移民与更新数据库-t：201211091112102_＆LT; migrationname＆GT; ，但无济于事。它仍然给我错误的脚手架。

What I also tried is adding the migrations I pulled from my coworkers one by one with update-database -t:201211091112102_<migrationname> but to no avail. It still gives me the erroneous scaffold.

那么我们做了什么错在这里，或EF根本没有建立像这样的合作？

So what did we do wrong here, or is EF simply not built for collaboration like this?

更新

我创建了一个重现的测试案例，这是一个有点冗长的舞蹈，虽然为了模拟这种多用户/多数据库场景。

I created a reproducible test case, it's a bit of a lengthy dance though in order to simulate this multi user/multi database scenario.

<一个href=\"https://github.com/JulianR/EfMigrationsTest/\">https://github.com/JulianR/EfMigrationsTest/

步骤来重现，当你有以上的项目（这些步骤也是美元的$ C $中c p $ psent）：

Steps to reproduce when you have the above project (these steps are also present in the code):

1. 添加迁移初始化


2. 更新数据库（在数据库'TESTDB'）


3. 更改连接字符串，使其指向TestDb1


4. 在TestDb1更新数据库


5. 在类测试取消注释属性美孚


6. 添加迁移M1财产美孚添加到TestDb1


7. 再次注释掉Test.Foo


8. 更改连接字符串，使其指向TestDb2


9. 从项目中排除迁移M1所以它不会应用到TestDb2


10. 在类测试取消注释属性栏


11. 更新的数据库来初始化移民申请TestDb2


12. 添加迁移的M2属性栏添加到TestDb2


13. 更改连接字符串再次指向原始TESTDB


14. 包含迁移M1到项目中再次


15. 在类测试取消注释属性美孚


16. 在类测试取消注释属性SomeInt


17. 更新数据库


18. 添加迁移M3


19. 更新数据库，得到一个错误，因为M3试图列美孚添加到这是已经刚刚迁移M1添加的数据库TESTDB。

上面的是模拟三个用户，其中用户1 inits他的数据库，另外两个使用他初始化创建其数据库为好。然后，用户2和用户3都让自己改变数据模型，并将其与应用变化所需的迁移一起添加到源代码控制。然后，用户1拉用户2和3的变化，而用户1也进行了更改数据库的自己。然后，用户1呼叫更新数据库申请用户2和3的变化然后，他脚手架自己的迁移，然后错误地增加了脚手架从用户2或3的变化迁移时应用到用户1的数据库，这将导致一个错误。

The above is to simulate three users, where user 1 inits his database, the other two use his initialization to create their database as well. Then user 2 and user 3 both make their own change to the datamodel and add it to source control together with the migrations needed to apply the changes. Then user 1 pulls the changes of user 2 and 3 while user 1 has also made a change to the database himself. Then user 1 calls update-database to apply the changes of user 2 and 3. He then scaffolds his own migration which then erroneously adds a change from user 2 or 3 to the scaffolded migration which causes an error when applied to user 1's database.

推荐答案

您需要手动解决迁移冲突就像你code冲突。如果更新，有新的迁移，您需要确保上次迁移背后的元数据，当前模型相匹配。要更新迁移，重新发出添加迁移命令的元数据了。

You need to manually resolve migration conflicts just like you would code conflicts. If you update and there are new migrations, you need to ensure that the metadata behind the last migration matches the current model. To update the metadata of the migration, re-issue the Add-Migration command for it.

例如，前17​​步在方案（更新-数据库），你应该发出以下命令

For example, before step 17 (Update-Database) in your scenario, you should issue the following command

Add-Migration M2

这将更新元数据与当前模型把它同步。现在，当你尝试添加M3，它应该是空白，因为你还没有做出任何进一步的模型更改。

This will update the metadata to bring it in sync with your current model. Now when you try and add M3, it should be blank since you have not made any further model changes.

这篇关于迁移实体框架在协作环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！