EF Code First Database Initializer and Migrations Confusion

Question

I am on Entity Framework 6.0. This is a development issue, not Production.

I think I have a conflicting strategy in place. Currently I have a DropCreateDatabaseIfModelChanges database initializer set and have migrations enabled with a seed method in Configuration.cs. On adding a migration and running update-database, it seems like a lucky dip as to when the database is dropped and recreated and when the seed method runs. The fact is, it's a total lottery as to when either happens, and I have to pull all sorts of tricks to get the thing to work. Can someone tell me if it is conflicting to have both a database initialiser and migrations enabled. Thanks

Answer 1

That is not a proper combination. There is a MigrateDatabaseToLatestVersion Initializer for use with migrations.

During early development, you may want to use a DropCreateDatabaseIfModelChanges initializer (or CreateDatabaseIfNotExists). There is a special Seed() method for initializers that only runs when the database is created.

Once you reach a point where what's in the database is a pain to reseed you can switch to migrations. Change your initializer and enable migrations. Be sure to add an initial baseline migration (add-migration Initial -IgnoreChanges) so you will only get the changes after that point. You can now add migration Seeding that runs every time you update-database as opposed to the initializer Seed that only runs if the database is created.

If you need to recreate the database, you can generate an idempotent script that will create the database and apply all migrations.