Guys we moved Framework 7 to EF core 2.0 .So right now we have a Small problem.
when We use Entity Framework 7 its mostly easy to update client Database without any doubt.(update -database)
but in EF core there is a problem the reason is for every changes we have to add add-migration so in that case we have now 100 migration history.
example :(20180313063924_NewVersion,14689013063934_NewVersion etc)
so when we update client database we have to keep that 100 migration history
But i think this is not the good way when its come to production level
is there anyway to resolve this problem.it would be helpful so much thank you!!
Well, it is exactly the way like EF and EFCore are working.
Every migration represents the needed modification on DbContext/Database to be valid with model's changes. So if you have changes, they will be represented by a migration.
One - in my opinion - not very clean solution could be:
delete current database
delete whole Migrations directory (is valid too to delete all migration files and <yourContextName>Snapshot.cs file in Migrations directory)
add new migration e.g. InitialCreate
The result will be only one migration that represents your current project's model/dbcontext state.
The approach is only possible if the project is still in dev-phase without any deployments on any stages.
Please note, I don't recommend that solution/approach. In my opinion you should leave the migrations like they are.
For further information you should read following:
The Model Snapshot In Entity Framework Core
Migration in Entity Framework Core
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 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.
Maybe I'm defeating the purpose of Code First but for one reason or another let's look at the problem.
I'm working in EF Code First. My 'Cars' POCO has a "Make" field,.. that matches the "Make" column in the db. Now I come along and I manually rename the column in the db to "Manufacturer". How can I force EF to catch up and update/ rename the POCO?
At the moment I'm using EntityFramework 6.1.3 and VS 2010.
The only solution I could find to this problem of the database being out of sync with EF on the code side was to delete all of the MIGRATIONS and the ENTITIES poco classes, and on the db side delete the _migrations table. Then go back to your application and add to your project a new "Code First from Existing Database".
This solved the problem for me easily and will allow me to work with Code First AND SQL Server Management Studio (as I like to do (until I get better at EF)).
I know it's a bit of a work-around but it'll get you out of jail if you find yourself in this situation.
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.
We are using EF Code First with manual migration (AutomaticMigrationsEnabled = false;). The problem is that we need to share one database between two projects.
Project-A
---DbContext-A
---------Model1
---------Model2
---------Model3
Project-B
---DbContext-A
---------Model2
---------Model3
---------Model4
Some of the migration files are the same but some of them are different. For example: Project-B needs Model4 but Project-A doesn't..
Currently, If I update the database with one migration, DbContext will not work in other project.
What would be the best way to handle this scenario?
My feeling is that this is working against the intentions with migrations. I think that you should break out the DbContext, the entities and the migrations to a separate assembly that is shared between the two projects.
If that's not an option, you have to disable the compatibility check with the model. The compatibility check is done as part of the IDBInitializer.InitializeDatabase implementation, which is responsible for calling Database.CompatibleWithModel, so writing your own custom DB Initializer that does nothing would get you past that step. This also means that you take over the responsibility of ensuring that the database is compatible with the model. EF can't help you any more.