I'm using Entity Framework and Entity Framework migrations to implement solution using code-first and automatic migrations.
It used to work great but suddenly it stopped detecting the updates I make to my POCO. Now when I add a new property (very simple properties like age or email) and execute the Update-Database, nothing happens, and it gives me this:
Specify the '-Verbose' flag to view SQL commands being executed during migration.
Found 0 pending explicit migrations: [].
Adding seed data (if Seed method overridden in Migrations Settings class).
and nothing gets updated!
Has anyone any idea why this is happening?
This may be in two reasons:
There is some other DbContext in code, that's why automatic migrations could not decide, which context to use.
There is some new change, which loops a comparison of schema and code model, so EF simply could not find the difference.
In general, automatic migrations are simple and fast to implement, but it is not secured to use them. On some stage, such migrations could make a fail.
Several years ago, I have developed tiny ORM based on Linq2SQL, AcroDB Library, and it was using automigrations of SubSonic. Almost same as EF migrations can do now. It was perfect on small projects and small amount of data to process or change, but when project has grow into 15+ tables, it became a nightmare. That's why MS has announced Code-driven migrations lately. They are more secured and better for the project. Also, you can take a look to Migrator.Net (it is a bit better than EF, by this time).
Related
Desired outcome:
Use model first approach with Entity Framework and allow changes to deployed database/ model to be done automatically based on the changes in the model. Automatic schema difference script generation to allow smooth migrations.
Is there a way to perform migrations in model first EF6? I can see code first migrations topics all over, but nothing much on Model First.
Options I saw so far:
Database generation power pack (seems outdated)
somehow convert to code first, then use migrations (not desirable, as I like to have a visual designer)
somehow piggy back on code first migrations (http://blog.amusedia.com/2012/08/entity-framework-migration-with-model.html : this is for EF5, got error that can't run migrations on Model First)
some third party tools?
As far as I know there still is no automatic migration for Entity framework model first.
Our approach is:
Create a fresh database from the model.
Create a diff script to migrate the old database to the new one.
Verify that this diff script is indeed correct. Always double check what your automation tool creates.
We first used Open DB diff for our model first migrations. After that we switched to Redgate's SQL compare because it produced more reliable migrations .
In our experience DbDiff produced a lot of unnecessary SQL because it bothers with the order that columns are in, and has some other issues like foreign keys constantly being dropped and re-added. Aside from that it still did the job fine, but we had to do a lot of double checking on its generated SQL.
I have created an MVC project with Entity Framework Code First. The project has a decent sized database and is in Production. Now, I am adding a large new set of features that will pretty much double the size (number of tables) of the database. As I'm developing it, I expect to make a lot of tweaks to the POCO objects and Fluent model building logic. But, I don't want to have 100 "migrations" as I make little changes.
If I was doing Database First, I would change the database and recreate the model from it iteratively. When finished, I could compare the final schema with the previous schema and create the change scripts.
I am inclined to create a new temporary DbContext and develop my Code First model for the new tables there, recreating a new database from scratch as I iterate. And then when I have the model where I'm happy with it, move it over into the main DbContext and create one big migration. But this seems painful. It also has the problem that there are some relationships between new objects and existing objects that need to be put in place.
So, my specific question is how do I make many small changes to a Code First database:
Without re-creating the existing database
And without creating a (permanent) migration for each change I want to test
You say you created the project with Code First so you I assume you don't need to reverse engineer the database.
To avoid recreating the existing database use a MigrateDatabaseToLatestVersion database initializer
To avoid creating a permanent migration for each change, you could rollback each minor change then force the migration to re-run.
To rollback: Update-Database -TargetMigration 0
To force migration to re-run: Add-Migration "OneMigrationToRuleThemAll" -Force
On the other hand....
Learning to stop sweating the small stuff involves deciding what
things to engage in and what things to ignore
(Richard Carlson)
These tips for Entity Framework migrations are worth a read
I'm using EF 5.0 and I would like to start using Code-based migrations
I've used fluent migrator and there is a concept of migration order. Migrations can be migrated/rollback no matter the database's migration version.
Does Entity Framework have similar functionality?
I was planning on keeping multiple migration implementations for each database version (likely tied to sprint number at first).
Why do i want this?
Our continuous integration will migrate the database for each environment. It's likely that our Dev build will only be one version "behind" but when we go to QA or PROD environment the database will be behind by multiple migrations.
Maybe i'm going about this the wrong way, in which case I would love to hear opinions on the best way to do migration with CI.
Yes EF has this functionality.
When you run Add-Migration you'll notice the migration file is prefixed with a timestamp. This is what determines the order, assuming automatic migrations are and always have been disabled.
If you are using a mixture of explicit migrations and automatic migrations then you may notice an additional Source property in the .resx file generated with your migration. This is how EF will determine if it needs to run an automatic migration before it runs your explicit migration.
My experience has taught me these guidelines:
1) Never use automatic migrations.
2) Every developer on your team should ensure they have the latest code before creating a new explicit migration. Sort of obvious, but creating migrations from stale code will result in problems.
3) Developers should make sure that if they write custom SQL in the Up() method of the migration then they write appropriate code (and test it!) to reverse those changes in the Down() method.
Background:
I'm developing an application with Entity Framework Code First and have been using my POCO Model to describe the database schema as much as I can. However there are a few cases where only the migrations API supports what you want (such as adding an index). I didn't want to start adding migrations until later, it's much faster just to recreate the database at this point, however it seemed like the only option.
So I thought I'd see if I could see if migrations would work. I planned on using them eventually and I was hoping I'd just be able to adjust the Initial migration or regenerate it as I went, until it was time to make real migrations. However I had no real luck with this approach either. It seems like code migrations for entity framework are fundamentally flawed in that they force the schema to be stored (serialized) as part of the migration.
For me it meant that there was no possible way to adjust the migration as I had no way to update the Target property (which is essentially a serialized version of my model). I also can't regenerate the migration because there is no way to express the indices separately. Part of the problem is that the way migrations work forces them to be made in a serial fashion, which is terrible when I want to update past migrations or there are multiple developers.
I've therefore chosen to just use context.Database.ExecuteSqlCommand to add the indices however I want to figure out if this limitation in migrations is going to change in the future or if I can work around it.
Question:
Is there any way to update the IMigrationMetadata for an existing migration and is there a way to have a migration that doesn't need the metadata found in the Target field?
Our application has two contexts into the same application database. Each context is cleanly divided across their separation of concerns.
Now it seems that if I have two contexts, Context1 and Context2 and if I only change Context2's classes, EF 5.0 thinks even Context1 has changed. That seems to confuse EF 5.0 and seems to trigger migrations on both. After that incorrect detection, the resulting migrations are also inconsistent. We at a weird dead end due to that and our own oversight and most likely have to rebuild the entire db all over again :( (the up and down paths are inconsistent)
So, questions:
Does EF 5.0 support model-change detection and migrations for multiple contexts? I read this EF 4.3 stackoverflow question and also this MSFT post by Rowan before considering asking this here. I don't think this is a repeat since EF 4.3 => EF 5.0 improvements target code-first and migrations.
If not, when are you guys (MSFT/Rowan!) planning to support it?
Thx
Background story details (can be skipped):
We carefully set both 'schemas' via with code-first fluent api, added test data, tested it out and then added 'live' (alpha stage) data. Context1 bore critical 'live' info so we left it untouched and I then modified the 2nd context (context2 here) by adding a new member to the code first class (new column in table in db terms). When I ran the app, it seems to have detected BOTH as changed! At our end, thinking the unchanged Context1 won't be called, we didn't comment out the
Database.SetInitializer<Context1>(new DropCreateDatabaseIfModelChanges<Context1>()); we added during bringup. So it wiped out our critical now-grown tables! Yes, we should have taken it out as simply locking down the class definition wasn't good enough.
Multiple context to single database doesn't work very well yet but there should be a simple workaround. Create one more context which will never be used in your application logic except the migration. Add entity mapping for all entities from other contexts to this central context used for database creation / migration.
Btw. EF is open source so you can contribute and add support for multiple context yourselves.