Question:
Hi!
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 may happen that generated migrations are not executed. This was due to a migration with a lower timestamp, the last one recorded in the database, not being executed.
A little later, I left the company and from then on I only worked with NHibernate and migrations using MigSharp. However, for reasons of organization and practicality, I have always preferred Entity and have been thinking about the possibility of implementing it in new company projects. The issue of this obligation to run migrations in order would not work here: If the master branch suffers 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 mentioned, 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 the development of tasks along with last-minute fixes, or even continuous integration processes when performing a push?
Thanks!
Answer:
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 migrations engine. In this case, the migration device checks if there are any pending changes and automatically executes them. You don't even 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 the development of tasks along with last-minute fixes, or even continuous integration processes when performing a push?
Delete all collision migrations and generate a new one. Let's assume any 3 migrations, with the penultimate one in conflict 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