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?
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 have an application already in production using EF 5.0. I'm about to start on the next major revision. But before I do that, I'm trying to clean up a lot of my existing code.
One thing I want to change, is use a different class for one of my table entities. The new class is functionally identical to the previous. The only real difference is the name. E.g. ReceiptEntity will become Receipt.
This is to help simplify things, and stick to a simple naming convention.
However, EF Migrations are wanting to drop-recreate the table. This is not an option because the application is already in production. And I cannot allow for any data-loss.
Is there any way to change the Entity type without recreating the table that would make EF happy?
I was able to fix this by altering the generated migration.
The generated migration tried to create a table(one that already existed), then immediately drop it(which would of resulted in the data-loss).
I deleted all of the generated code, and simply 'Update-Database'ed an empty migration, and this solved the problem for me.
Working on a brand new project from the ground up. That means the data model is in a constant flux, doubly so because things are, inevitably, not as well planned as they should be. Model classes are being created and changed fairly regularly.
The plan was to use the latest version of EF with all the neat code-first stuff in it. But we're constantly tripping over the limitations the framework has in terms of adding or updating tables. The initialization options seem to allow only the complete deletion and re-creation of the database, which isn't really ideal.
I've had a look at the migrations. But this seems a sledgehammer to crack a nut: we don't need to detail every single small change and update with a new migration scaffold.
Are there some better strategies to deal with this? For instance, I started writing some unit tests to pre-populate one of the contexts with some test data, but because this causes the whole Db to drop and re-create, it causes problems with all the other contexts. Or perhaps making use of a custom initialiser to seed the data for us? How can we easily exclude these in production code?
We're also wondering about perhaps abandoning code-first and going back to EDMX diagrams. At least that way changes result in updated SQL commands which can be run directly against the database.
Any suggestions gratefully received.
I think, imho, that:
as the database schema must at least match your model you should/must detail every single change, and code first migration allows that and trace the changes over time
code first migration also allows to migrate the database schema for you
code first migration also allows you to produce sql that allows you to migrate the schema
For these reasons code first is as good (if not better) as the edmx approach
Please take few minutes to implement http://msdn.microsoft.com/en-us/data/jj591621.aspx
One other point, always imho and in a perfect world, if you unit test the business of you model you should not need the DAL, use generic collection. Be aware of different comportement of linq to object vs linq to entities, for example concerning the case sensitivity.
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).