I am using EF Core 2.0 in my sample project with some value object configurations. I modify the code and generate migrations via CLI command line. In the last migration rather than adding a new database table as it should, it is trying to rename existing tables to each other and create an extra table for existing one. I could not figure out the reason for it.
Issue is, since with EF Core the snapshot is a separate auto-generated file from the migration itself I don't want to modify the snapshot.
I only want to modify the migration script so that it will not rename multiple tables, and then generate the snapshot from the migrations I created.
I did not see any command for this in the CLI - is it such a bad practice to modify the scaffolded migration and regenerate or am I missing some obvious new link where how to manually modify migration scripts is explained?
Thanks a bunch.
Update 1: After comments, added info about the snapshot from this link.
Because the current database schema is represented in code, EF Core doesn't have to interact with the database to create migrations. When you add a migration, EF determines what changed by comparing the data model to the snapshot file. EF interacts with the database only when it has to update the database. +
I examined my generated snapshot code from source control. It exactly has added one extra table as what I needed.
The migration script to generate this is hectic at best - renaming multiple tables to each other and then warning that this could break causing multiple issues.
Since this is a sample project for me with only mock data as of now at least, I decided to go for it and not break the automated scripts. I am willing to lose some mock data at this stage rather than wasting time on it.
If this were in a production database I would be extremely careful to manually create the same result with intervention modifying both the scaffold and the migration file.
I am accepting this one as an answer (basically saying current EF Core does not support it to the best of my current knowledge) since there is no other candidate now - I will be more than glad to accept if any better answer shows up.
Related
Due to my current project structure where I need to handle many database-views I would like to write the Ef-Core Migration-Classes manually.
We are using the code-first-approach.
I know frameworks like the php Phinx where I can simply create migration files manually.
Is this also possible with ef core, without using database ef migrations add?
Update
I tried to create the migration file manually, but then it isn't executed on context.Database.Migrate().
Is that because of the missing .Designer-file or the Snapshot-File that is not changed?
Do I really need the Snapshot and Designer files? I guess the migration-system tracks executed migrations within the history database table?
Update 2
I changed from EF-Migrations to FluentMigrator. This module solves all my problems.
I'm using EF6 code-first migrations for existing database but initial DbContext does not fully cover existing schema (since it's massive). So from time to time I have to make updates to the model in database-first style. For example when I need an entity mapping for a table or a column that is already in the database but not reflected in the code I do the following:
Make all change (add new entity, rename the column mapping or add new property)
Scaffold migration representing the latest model snapshot stub_migration
Copy-paste latest serialized model from stub_migration to the last_migration resource file
Delete stub_migration
Revert last_migration in database
Update-Database so that model snapshot in [__MigrationHistory] table would be also updated
I understand that this aproach is a bit hackish and the proper way would be to leave empty stub_migration but this would force lots of empty migrations which I would rather avoid.
Looking at a similar scenario from MSDN article (Option 2: Update the model snapshot in the last migration) I wouldn't imagine that there is an easier way rather than writing power shell script, managed code or both to make it work. But I would rather ask community first before diving deep into it.
So I wonder: is there a simple way to automate generation of new model snapshot in latest migration and reaplying it?
I'm doing something similar. I have a large database and I am using the EF Tools for VS 2013 to reverse engineer it in small parts into my DEV environment. The tool creates my POCOs and Context changes in a separate folder. I move them to my data project, create a fluent configuration and then apply a migration (or turn automigration on).
After a while I want a single migration for TEST or PROD so I roll them up into a single migration using the technique explained here: http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1
You can simplify the steps for updating DbContext snapshot of the last migration applied to database by re-scaffolding it with Entity Framework:
Revert the last migration if it is applied to the database:
Update-Database -Target:Previous_Migraton
Re-scaffold the last migration Add-Migration The_name_of_the_last_migration which will recreate the last migrations *.resx and *.Designer.cs (not the migration code), which is quite handy.
Those 2 steps are covering 4 steps (2-5) from original question.
You can also get different bahavior depending on what you want by specifying the flags -IgnoreChanges and (or) -Force
And by the way, the major problem with the updating the DbContext snapshot is not how to automate those steps, but how to conditionally apply them to TEST/PROD environments depending on whether you actually want to suppress the warning because you've mapped existing DB-first entities in you DbContext or you want it it to fail the build in case you've created new entities and forgot to create a code-first migration for them.
So, try to avoid those steps altogether and maybe create empty migrations when you just want to map existing tables to your code.
When an application is Live an iterative approach to database changes is obviously required. In the db first world I would change the object (eg. column added to table) in the databaae project, then deploy (recreate) to my local instance, then replace the old table with the new in my edmx - when it was go Live time a delta script is generated out of the database project compared to a copy of the Live database schema. Sounds long winded but at the end of the day I only made the change once (the object in the db project) - everything else is generated
Flip over to code first (EF6) and Im expecting a similar one change experience - i.e. I add the property to the class - however do I additionally need to add a migration script ?
I've been reading and it seems many advise to disable migrations to have more control - I'm confused - I had visions of simply deploying the app and the changes automatically reflected in the target database the next time the app runs - one thing is for sure I don't want to manually write separate deployment scripts (or migration code). As mentioned I'm confused about this final part - can anyone clarify - point out the options
Many thanks
Short answer is there's no need to create a 'migration script', you're correct as EF will handle it for you if you want. I think when you read about disabling migrations, you were probably actually reading 'disable automatic migrations'; EF will still generate migrations regardless.
As you pointed out it IS a two-change process when developing: First you change your class, then you open up the Package Manager console and call Add-Migration. Usually, that's all you have to do, and EF will generate the change code for you. Then, you call Update-Database and it does it's work. When you go to deploy, you will connect to your target database and call Update-Database once and it will apply all migrations that are pending.
You can also enable auto-migrations which skips the Add-Migration step, but I always like to review the generated code. Call me old-fashioned ;)
It gets more complicated when you need support for views, SPROCS, and UDFs, but there are ways to do most anything you want to do. And, even though it's a 2 (3?) step process to get changes out to the DB, it's still much easier than changing the DB and code separately, by yourself.
Then, you can follow the steps here to set your deployment up so that once your EF is initialized on a connection to your production DB, it automatically applies the updates. Again, I would advise to do it yourself (via the package manager console) just to be safe but it's not necessary.
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