Upgrading to Code Based Migrations EF 4.3.1 with Connector/Net 6.6
- by GABMARTINEZ
Entity Framework 4.3.1 includes a new feature called code first migrations. We are adding support for this feature in our upcoming 6.6 release of Connector/Net. In this walk-through we'll see the workflow of code-based migrations when you have an existing application and you would like to upgrade to this EF 4.3.1 version and use this approach, so you can keep track of the changes that you do to your database.
The first thing we need to do is add the new Entity Framework 4.3.1 package to our application. This should via the NuGet package manager. You can read more about why EF is not part of the .NET framework here.
Adding EF 4.3.1 to our existing application
Inside VS 2010 go to Tools -> Library Package Manager -> Package Manager Console, this will open the Power Shell Host Window where we can work with all the EF commands.
In order to install this library to your existing application you should type Install-Package EntityFramework
This will make some changes to your application. So Let's check them.
In your .config file you'll see a <configSections> which contains the version you have from EntityFramework and also was added the <entityFramework> section as shown below.
This section is by default configured to use SQL Express which won't be necesary for this case. So you can comment it out or leave it empty. Also please make sure you're using the Connector/Net 6.6.x version which is the one that has this support as is shown in the previous image.
At this point we face one issue; in order to be able to work with Migrations we need the __MigrationHistory table that we don't have yet since our Database was created with an older version. This table is used to keep track of the changes in our model. So we need to get it in our existing Database.
Getting a Migration-History table into an existing database
First thing we need to do to enable migrations in our existing application is to create our configuration class which will set up the MySqlClient Provider as our SQL Generator.
So we have to add it with the following code:
using System.Data.Entity.Migrations; //add this at the top of your cs file
public class Configuration : DbMigrationsConfiguration<NameOfYourDbContext> //Make sure to use the name of your existing DBContext
{
public Configuration()
{
this.AutomaticMigrationsEnabled = false; //Set Automatic migrations to false since we'll be applying the migrations manually for this case.
SetSqlGenerator("MySql.Data.MySqlClient", new MySql.Data.Entity.MySqlMigrationSqlGenerator());
}
}
This code will set up our configuration that we'll be using when executing all the migrations for our application.
Once we have done this we can Build our application so we can check that everything is fine.
Creating our Initial Migration
Now let's add our Initial Migration. In Package Manager Console, execute "add-migration InitialCreate", you can use any other name but I like to set this as our initial create for future reference.
After we run this command, some changes were done in our application:
A new Migrations Folder was created.
A new class migration call InitialCreate which in most of the cases should have empty Up and Down methods as long as your database is up to date with your Model.
Since all your entities already exists, delete all duplicated code to create any entity which exists already in your Database if there is any. I found this easier when you don't have any pending updates to do to your database.
Now we have our empty migration that will make no changes in our database and represents how are all the things at the begining of our migrations. Finally, let's create our MigrationsHistory table.
Optionally you can add SQL code to delete the edmdata table which is not needed anymore.
public override void Up()
{
// Just make sure that you used 4.1 or later version
Sql("DROP TABLE EdmMetadata");
}
From our Package Manager Console let's type:
Update-database;
If you like to see the operations made on each Update-database command you can use the flag -verbose after the Update-database.
This will make two important changes. It will execute the Up method in the initial migration which has no changes in the database. And second, and very important, it will create the __MigrationHistory table necessary to keep track of your changes. And next time you make a change to your database it will compare the current model to the one stored in the Model Column of this table.
Conclusion
The important thing of this walk through is that we must create our initial migration before we start doing any changes to our model. This way we'll be adding the necessary __MigrationsHistory table to our existing database, so we can keep our database up to date with all the changes we do in our context model using migrations.
Hope you have found this information useful.
Please let us know if you have any questions or comments, also please check our forums here where we keep answering questions in general for the community.
Happy MySQL/Net Coding!
