Home .NET Automatic migration of the database to Entity Framework

Automatic migration of the database to Entity Framework

by admin

In the process of software development, when not all the functionality is defined yet, the database structure often changes. And if you use any ORM-framework, changing the database after the data model has changed is quite inconvenient (in fact, you need to do double work to change the model class and the database structure). In a nutshell, how to do the migration in EF 4 Code First with the Package Manager Console is described here I’ll try to describe how to do automated migration without developer’s participation (or more precisely, with a minimal participation).

Where it all began

The task of creating a new project, which is something like ARM a.
After some deliberation, we decided to use Entity Framework Code First, because in the future it is possible to change DBMS and with this variant we just need to change the connection string (if there is a suitable ADO.NET provider).
Made data models, context class inherited from DbContext’a :

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 write (in our case in Global.asax) the initializer :

Database.SetInitializer(new ProjectInitializer());

All seemed fine, who does not have a database it is created, but after clarifying the details with the customer, it became necessary to add more entities. And since the development is conducted by several developers, there was a mass recreation of the database, and the data were already there are real.

Migrations

This is how we came to migrations. As advised by article ran the command in the Package Manager Console :

PM> Add-Migration 1

In the project appeared a folder Migrations, which created two files: Configuration.cs, <date_time> _1.cs. The first one, as the name implies, the configuration of migration, the second contains the necessary changes in the database to update / rollback the version. Next, just execute in the NuGet console :

PM> Update-Database

Everything was fine, if someone’s model didn’t match the database, they just did a migration in the console and deleted the migration file. Until it was time to host the project on the customer’s server. NuGet was not there, and there was no opportunity to install it either (and the hosting provider has no such opportunity in principle, if you don’t take the server).

Automatic migration

Trying to figure out how to do automatic migration, armed with IntelliSense, So I did it by trial and error. found out by empirical method that you need to change the class the initializer inherits from :

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

Started up and got this exception :
Automatic migration of the database to Entity Framework
Aha! Doing what is suggested in the exception post, that is :

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

run it and see that the migration is automatic.
We achieved what we wanted and now migrations are done without any developer involvement, but I mentioned that some involvement is still needed, for example if you rename a model property and run the project, you will see the following exception :
Automatic migration of the database to Entity Framework
The point is that in terms of Entity Framework renaming a property is deleting and adding with a new name, and in this way data loss is possible. In such cases (and there are few of them), you just need to create migration manually with Add-Migration command and manually correct DropColumn and CreateColumn to RenameColumn (or something else, depending on the situation).

Conclusion

That’s all, I hope this article will be useful. And also hope that the information from the original source on the subject is very little, because it’s like a beta version and with the release of Entity Framework 5.0, will not have to search through trial and error to find the right way to use.

You may also like