I just installed Entity Framework Migrations, added a property to a class, and gave EF Migrations a whirl.
My development database was promptly updated. So far, so good.
Now, I want to create a change script for this initial use of Migrations for the production database. Note there was a pre-existing database because I applied this to an existing project.
The migrations I have are:
PM> Get-Migrations
Retrieving migrations that have been applied to the target database.
201204102238194_AutomaticMigration
201203310233324_InitialCreate
PM>
I thought I could get a delta script using the following:
Update-Database -SourceMigration:201203310233324_InitialCreate -TargetMigration:201204102238194_AutomaticMigration -script
However, that gives me the error:
'201204102238194_AutomaticMigration' is not a valid migration.
Explicit migrations must be used for both source and target when
scripting the upgrade between them.
Just to see what would happen, I reversed the two parameters (backward migration) and did get the script I would expect after adding the -force flag (new columns dropped).
How can I get a script for this first migration?
The right way to start using EF migrations with an existing database is to start with adding an empty migration that contains the metadata of the current database.
I think that you have to roll back to a model that is compatible with the initial database schema. Then run the following command:
add-migration InitialSchema -IgnoreChanges
That should give you an initial migration, that does nothing, but contains the metadata of the current model. You can of course add migrations later with -IgnoreChanges if you've expanded your code model to cover more of the tables already present in the database.
Once you have that initial migration step in place, the scripting would work.
Generally I would not recommend to use automatic migrations unless you only ever intend to only use automatic migrations. If you want some kind of control over the changes to the database (including scripting them) then code-based migrations is the way.
Related
We have a project running EF6 and have now activated Migrations. The problem we have is that we ha a lot of Data that needs to be added to the database when it is created. This worked well until we needed to add data in the migration part so it is part becomes part of the SQL script. Because when we try and create a new database on our development machines the migration steps are done before the Initializer's seed method and some of the data in the migration step depends on that seed data.
Is there some way to just get the initial database, without any migrations, plus the Initializer's seed data? Or do we need to move the critical data to the InitialCreate mirgations Up method?
The production database will cannot be wiped at this stage and thus we need to add all new production data to the migration step.
Edit: In the end we just moved the effected data to the Up method in migrations, not the way I wanted to do it but we where short on time and this solved the problem.
Migrations also have a Seed method you can override that takes place after the Up() method. You can use the AddOrUpdate command in case data may exist. http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-3
I am using EF code first and asp.net MVC. Here is my technical stack.
Visual Studio 2010
Entity Framework 4.3.1
In my migrations folder, I can see three migrations files are existing.
InitialCreate
AddStandardException
DocumentScope
When I check my database I can see that _MigrationHistory table has all three migrations applied. Now I have added one more DbSet, and I want to write migrations for it. When I attempt to give this command
Add-Migration NewTable
It gives me this error :
Unable to generate an explicit migration because the following explicit migrations are pending: [201402121621095_AddStandardException, 201402190713571_DocumentScope]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
I don't understand why is it complaining about pending migrations whereas all migrations have been applied?
How do I even troubleshoot this ? I tried with -Debug switch but no luck.
I found a workaround to it. I have just commented code inside the Up() and Down() functions. Then ran Update-Database. It applied some dummy migrations and then reported that
Unable to update database to match the current model because there are
pending changes and automatic migration is disabled. Either write the
pending model changes to a code-based migration or enable automatic
migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to
true to enable automatic migration.
After this when i ran
Add-Migration NewTable
It gave me the correct result. Any idea whats going on here ?
You either need to run "update-database" from the package manager console to push your changes to the database OR you can delete the pending migration file ([201402121621095_AddStandardException]) from your Migrations folder and then re-run "add-migration" to create a brand new migration based off of your edits.
Explanation: "update-database" basically modifies existing table fields while "add-migration" works like git by making a snapshot of the distinct model changes. These snapshots show how the database evolved over time so they are more useful to your code user than the EF or the App itself.
That being said, it is possible that your newer classes have a quite different code signature which may not "flow" with the existing classes.
Solution: Modify or remove the previous migrations since the new migration will create a new data structure that won't use or need them
I've noticed that when I create a code first database migration using add-migration it generates a Down() method as well as an Up() method.
How do I tell my database to downgrade?
After almost giving up with researching on Google I managed to find this quote from here:
http://msdn.microsoft.com/en-gb/data/jj591621.aspx#specific
Which Specifies:
Let’s say we want to migrate our database to the state it was in after running our AddBlogUrl migration. We can use the –TargetMigration switch to downgrade to this migration.
Run the Update-Database –TargetMigration: AddBlogUrl command in Package Manager Console.
This command will run the Down script for our AddBlogAbstract and AddPostClass migrations.
If you want to roll all the way back to an empty database then you can use the Update-Database –TargetMigration: $InitialDatabase command.
First get the name of the migration that was applied before the one you want to downgrade by issuing the Get-Migrations command.
PM> Get-Migrations
Retrieving migrations that have been applied to the target database.
201508242303096_Bad_Migration
201508211842590_The_Migration_applied_before_it
201508211440252_And_another
This list shows the migrations listing the most recent applied migration first. Pick the migration that occurs in the list after the one you want to downgrade, ie the one applied before the one you want to downgrade.
Update-Database –TargetMigration: "<the migration applied before it>"
All migrations applied after the one specified will be down-graded in order starting with the latest migration applied first.
Using Entity Framework 5, we're using Code-First Migrations in our application. Every developer has his own database on which they work.
I have accidently emptied mine: There is nothing in there anymore, no tables, not even the migration history table.
So, I've tried to update the database again through the PM console by executing update-database. It immediatley gives me an error that a table does not exist, while it should be created in my inital code migration.
What is interesting is that the PM console also shows what migrations are being applied, which does not contain the inital create code migration, thus not creating any tables at all, and ofcourse failing at later migrations.
I tried executing update-database -targetmigration:initialcreate which gives me the message that that code migration does not exist, while it is a direct copy/paste from the cs file, so the id must be correct (note: this works for other migrations).
I also tried update-database -targetmigration:0 and update-database -targetmigration: $InitialDatabase which both give me 'Target database is already at version 0'.
I've also tried deleting the database altogether and let EF create it for, didnt work either, it keeps skipping the initialcreate migration.
So how do I get Code Migrations to execute my initalCreate code migration?
Working with EF migrations in a team scenario is not ideal to say the least. The best practice my team follows is to never commit migrations. Migrations are personal and apply only to your particular database instance. If everyone commits their own migrations you end up with a mess, quick.
While not directly related to your question, some may wonder how you deal with production migrations. Simply, you don't. Your Release Manager, or whoever will actually push the release live, should generate SQL to apply all the changes at once, and then hand this off to your DBA, or whoever manages the production database.
That said, in the scenario that you describe, where you database has been emptied. The best fix is to delete all migrations in your Migrations folder. Even and especially, the initial migration (they don't matter, anyways, because you shouldn't be holding on to them outside of your personal codebase). Then generate a new migration, which will trigger EF to compare your current database state (empty) with the state of the app and essentially create a new initial migration based on the current state of your app. Then, you can apply this migration.
I have been developing my app in a code-first approach atop an exisiting database.
Only now do I have a need to run a migration. I don't want to destroy this database when my model changes because it is very large and it has nice sample data in it.
How can I run a migration without the framework telling me that there are pending changes to apply? (The code runs anyway as I do my migrations from Rails-tho I would like to do them from here)
I do not want to set up automatic migrations because I am working on a big database with lots of seeded data that I do not want to delete/recreate. I also want to have control over what is made, deleteded and when.
This is also needed for when I take it to production, I'd like to roll out the changes via Migration instead of manually. How can I migrate by adding in/removing the fields I want and not have EF care about what it is I do?
If I know how it knows which one it is on (like Rails) can I trick her into thinking that she can run the migrations I want?
I thought that setting the initializer by:
Database.SetInitializer<MyDbContext>(new CreateDatabaseIfNotExists<MyDbContext>
would take acre of it, but it does not.
To answer the question in the title, because there's a sys table __MigrationHistory which tells EF that there is a difference in your tables vs what the database has.
As far as how to do it (from package manager console):
Enable-Migrations
In the configuration class set AutomaticMigrations = false;
Set your Database.SetInitializer<Context>(null) so it doesn't DropCreate or Update
AddMigration <name> to queue any pending changes to a change model
Update-Database will call the MigrationName.Up method to alter the database with any changes (sans losing data).
There's a Table "__MigrationHistory" that EF uses to store Migration Name / Order. You can backup this table in your dev environment, then delete these records. When you deploy to production, you run the migrations. Another option is use Database compare (dev / prod) and get scripts to change your tables / data.