Order of execution of Migrations

Question

Hello!

In my first job, I worked using code-first with Entity Framework 4. At this time, I noticed a limitation in it: the generated Migrations only ran in order. For example, if in my branch two people are working with persistence, it can happen that generated Migrations are not executed. This was due to an Migration with minor timestamp the last registered in the bank not be executed.

A little later, I left the company and from there I worked only with Nhibernate and Migrations using Migsharp. However, for the sake of organization and practicality I always preferred the Entity and I was thinking about the possibility of implementing it in new projects of the company. The issue of this requirement to run Migrations in order would not work here: If the master branch suffers a last-minute persistence correction to solve problems already in production, the development branch would have to change all the timestamp of the already created Migrations that are not yet in master, or the Migrations would not be executed.

As I commented, I had this problem in Entity Framework 4. My question is: In the new versions of Entity Framework is there any configuration that allows the execution of Migrations without a mandatory order? If not, what’s the most 'professional' way to prevent problems like this from occurring during job development along with last-minute fixes, or even continuous integration processes when pushing?

Thank you!

Answer 1

In the new versions of the Entity Framework there is some configuration that allows the execution of Migrations without a mandatory order?

Yes, the automatic migration mechanism. In this case, the migration device checks for any pending changes and executes it automatically. No need to generate new migrations.

This mechanism is recommended to use when the project is at the beginning and these collisions are common. Once the system is ready to go into production, it is recommended to go back to manual migrations.

If not, what’s the most 'professional' way to prevent problems like this from occurring during job development along with last-minute fixes, or even continuous integration processes when pushing?

Delete all collision migrations and generate a new one. Let’s assume 3 any migrations, and the penultimate conflict in something with the last:

201603152143014_Migration1.cs
201603161530010_Migration2.cs
201603182010501_Migration3.cs

We need to revert to Migration1 and delete the other two. We therefore use:

PM> Update-Database -TargetMigration:201603152143014_Migration1

Then we use the routine commands:

PM> Add-Migration Migrations2e3
PM> Update-Database