I've enabled code-first migrations on my entity framework project, and have added several migrations which do things like rename tables. However, I have now deleted the database and caused entity framework to generate a brand new database based on my latest data model. If I try to run:
PM> Add-Migration TestMigration
... it tells me that I need to apply the existing migrations first. So I run:
PM> Update-Database
... but the trouble is that it's trying to update a database that doesn't need updating; it's already based on the latest data model. So I get an error when it tries to rename a table that now doesn't exist.
Is there some way I can indicate to data migrations that my database is up-to-date and doesn't need any migrations running on it? What should I do?
This implementation does not need to manually maintain records to be inserted to
__MigrationHistory
. Migrations are determined from assembly specified.Maybe this helps.
My thanks goes to @Jez for initial idea.
Go to
MigrationHistory
table in sql server (undersystem
folder) it has row for your migration and db hash in it which must be the same with one in your migration file, just copy it from db to file.In other words you need to sync your
MigrationHistory
table with actual migrations.I've found a way to indicate that my database is up-to-date, and it's (unsurprisingly) based on modifying the
__MigrationHistory
table, which code-first migrations uses to determine which migrations to apply to the DB when you runUpdate-Database
.By the way, whilst researching this answer I came across a very nice reference for code-first migrations commands, which can be found at: http://dotnet.dzone.com/articles/ef-migrations-command
When the database is created from scratch automatically by EF, it will always put a single entry into the
__MigrationHistory
table, and that entry will have the MigrationId(currentDateTime)_InitialCreate
. This represents the initial creation of the database that EF has just carried out. However, your migration history is not going to begin with that MigrationId because you will have started with something else.To "fool" code-first migrations into thinking that you're on the latest migration, you need to delete that
(currentDateTime)_InitialCreate
entry from the__MigrationHistory
table of the newly-created DB, and insert what would have been there if you still had the old DB which had had the migrations applied to it.So, first delete everything from the newly-generated DB's
__MigrationHistory
table. Then, go into package manager console and run:From the resulting SQL script, pull out all the lines beginning with:
Then, run those
INSERT
statements within the context of the newly-created database. Check that each of those rows now exists in your__MigrationHistory
table. When you next run:... you should get a message saying "No pending code-based migrations." Congratulations - you've fooled code-first migrations into thinking you're now on the latest migration, and you can continue where you left off adding new migrations from here.
I do think there should be some automated way of doing this built into EF code-first, though... maybe they should add something like:
... whereby it would clobber the existing entries in the migrations table, and just insert the new entries into migrations history for each migration defined in your project, but not actually try and run the migrations. Ah well.
UPDATE
I've found a way to automate this nicely, using a custom initializer's Seed method. Basically the Seed method deletes the existing migration history data when the DB is created, and inserts your migrations history. In my database context constructor, I register the custom initializer like so:
The custom initializer itself looks like this: