Execution order of migrations

4

Hello

On my first job, I worked using code-first with the Entity Framework 4. At this time, I saw a limitation on it: the generated migrations only ran in order. For example, if two people are working with persistence in my branch, generated migrations may not run. This was due to a migration with less than the last timestamp registered in the database not being executed.

Shortly thereafter, I left the company and from there I only worked with NHibernate and migrations using MigSharp. However, for the sake of organization and practicality I have always preferred Entity and I have been thinking about the possibility of implementing it in new projects of the company. The issue of this mandatory migration of migrations would not work here: If the master branch undergoes a last-minute persistence fix to solve problems already in production, the development branch would have to change the entire timestamp of the migrations already created and that are not yet in the master, or else the migrations would not be executed.

As I said, I had this problem in Entity Framework 4. My question is: In the new versions of the Entity Framework is there any configuration that allows the execution of migrations without a mandatory order? If not, what is the most 'professional' way of avoiding problems such as these occurring during the development of tasks alongside last-minute fixes or even continuous integration processes when pushing?

Thank you!

    
asked by anonymous 21.03.2016 / 22:40

1 answer

3
  

In the new versions of the Entity Framework is there any 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 them automatically. It is not even necessary to generate new migrations.

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

  

If you do not, what is the most 'professional' way of avoiding problems such as these occurring during the development of tasks alongside last-minute fixes or even seamless integration processes when pushing?

Delete all migrations with collision and generate a new one. Let's suppose 3 any migrations, and the penultimate one conflicts in something with the last one:

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
    
21.03.2016 / 23:47