Automatic database migration to the Entity Framework

In the process of software development, when not all the functionality is finally defined, the database structure often changes. And if any ORM-framework is used, changing the database after changing the data model gives some inconvenience (in fact, you need to do double work on changing the model class and database structure). In brief, how to make migration to EF 4 Code First using the Package Manager Console is described here , I will try to describe how automatic migration works without developer participation (more precisely, with minimal participation).

How it all started

The challenge was to create a new project, which is something like an AWP and.

After some discussion, we decided to use the Entity Framework Code First, since in the future, a change of the DBMS is possible, and with this option we will just need to change the connection string (if there is a suitable ADO.NET provider).

Made data models, context class, inherited from DbContext:

public class ProjectContext : DbContext { public ProjectContext() { } public ProjectContext(string connString) : base(connString) { } public DbSet<Address> Addresses { get; set; } ... } 

added initializer:

')

 public class ProjectInitializer : DropCreateDatabaseIfModelChanges<ProjectContext> { protected override void Seed(ProjectContext context) { ... } } 

and prescribe (in our case in Global.asax) the initializer:

 Database.SetInitializer(new ProjectInitializer()); 

Everything seems fine, who does not have a database to create, but after specifying details for the customer, it became necessary to add more entities. And since several developers are developing, there was a massive re-creation of the database, and the data there was already real.

Migrations

So we came to migrations. As the article suggests, execute the command in the Package Manager Console:

 PM> Add-Migration 1 

The project has a folder Migrations, which created two files: Configuration.cs, <date_time> _1.cs. The first, as the name suggests migration configuration, the second contains the necessary database changes for updating / rolling back the version. Next, just run in the console NuGet'a:

 PM> Update-Database 

Everything was great, if someone didn’t have the same model as the database, he just did the migration to the console and deleted the migration file. Until it is time to place the project on the server of the customer. NuGet wasn’t there, and there wasn’t any opportunity to establish opportunities either (and the hosting provider doesn’t have such a possibility, in principle, if you don’t take a server).

Automatic migration

Trying to figure out how to do automatic migration, armed with IntelliSense, using empirical method of scientific testing, we found out that we need to change the class from which the initializer is inherited:

 //public class ProjectInitializer : DropCreateDatabaseIfModelChanges<ProjectContext> public class ProjectInitializer : MigrateDatabaseToLatestVersion<ProjectContext, Configuration> { ... } 

Launched and received such an exception:







Aha We do what is proposed in the exception message, that is:

 public sealed class Configuration : DbMigrationsConfiguration<ProjectContext> { public Configuration() { AutomaticMigrationsEnabled = true; } protected override void Seed(ProjectContext context) { } } 

we start and see that migration passes automatically.

We achieved what we wanted, now migrations take place without the participation of the developer, but I mentioned that we still need some participation, for example, if we rename the model property and run the project, we will see the following exception:







The fact is that from the point of view of the Entity Framework, renaming a property is deleting and adding with a new name, and thus data loss is possible. In such cases (and there are some of them), you just need to create a manual migration with the Add-Migration command and manually correct the DropColumn and CreateColumn to RenameColumn (or something else, depending on the situation).

Conclusion

That's all, I hope the article will be useful. I also hope that there is very little information from the original source on this issue, because it’s like a beta version and with the release of Entity Framework 5.0, it’s not a matter of trial and error to search for the right use case.