Question

I recently changed an application from using the following for dev:

DropCreateDatabaseIfModelChanges<Context>

To using:

public class MyDbMigrationsConfiguration: DbMigrationsConfiguration<GrsEntities>
{
    public MyDbMigrationsConfiguration()
    {
        AutomaticMigrationsEnabled = true;
        AutomaticMigrationDataLossAllowed = true;
    }
}

In my db context I have:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    // Tell Code First to ignore PluralizingTableName convention
    // If you keep this convention then the generated tables will have pluralized names.
    modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();

    //set the initializer to migration
    Database.SetInitializer(new MigrateDatabaseToLatestVersion<GrsEntities, MigrationConfig>());
}

I have overridden Seed(context) in DbMigrationsConfiguration using the AddOrUpdate extension where I was just using Add before with seeding on the drop db (DropCreateDatabaseIfModelChanges).

My confusion is that the Migration runs with each start of the application regardless of there being any changes to the DbContext. Each and every time I start the application (library run through a service) the initializer runs as does the Seed. My expected behaviour is a check whether a migration is necessary (behind the scenes check to see if model matches physical db) then update any new/removed tables/columns and only run seed if something has changed.

In my testing seed runs every time, which is workable but seemingly inefficient and was not what I expected. Unfortunately the MSDN documentation is quite limited.

Am I completely misusing MigrateDatabaseToLatestVersion? Is there any way to get the behaviour I expect (i.e. only seed if there is a model change) or should I just change my seed method to expect to be run every application launch?

Answer 1

The fact that the Seed method ran only when the database changed was quite limiting for the database initializers that shipped in EF 4.1. It was limiting because sometimes you needed to update seed data without changing the database, but to make that happen you had to artificially make it seem like the database had changed.

With Migrations the use of Seed became a bit different because it could no longer be assumed that the database was starting empty–that’s kind of the point of Migrations after all. So a Seed method in Migrations has to assume that the database exists and may already have data in it, but that data might need to be updated to take into account the changes made to the database for the Migrations. Hence the use of AddOrUpdate.

So now we have a situation where Seed must be written to take account of existing data, which means that there is really no need to perpetuate the limitations of the EF 4.1 Seed method such that you would have to make it seem like the database had changed just in order to get Seed to run. Hence Seed now runs every time the context is used for the first time in the app domain. This shouldn’t change the way Seed is imlemented since it needs to handle the case where the data is already present anyway.

If it causes perf issues because you have a lot of Seed data then it is usually quiet easy to add checks into the Seed method that query the database to determine how much work needs to be done before doing it.