I'm setting up EF Core 3.1.3 migrations against an existing SQL Server database.
This is what I've done so far:
Scaffold my model from the existing database.
Add the InitialCreate migration.
Remove the contents of the Up() method in InitialCreate.
Update database to create the __EFMigrationsHistory table.
Then I added a property to an entity class and ran dotnet ef add migration.
Now looking at the BuildTargetModel method of the second migration I see that it contains pretty much the same code as MyDbContextModelSnapshot.BuildModel. I.e. it lists all entities and all their properties and relationships.
What does BuildTargetModel on a migration do? Why does it have to duplicate most of the snapshot code? I would only expect to find the diff in a migration.
As confirmed by the developers of EF Core, this behaviour is by design:
https://github.com/dotnet/EntityFramework.Docs/issues/2288
Related
I am learning entity framework. I am reading through some tutorials about initialization and how there are
CreateDatabaseIfNotExists
DropCreateDatabaseIfModelChanges
DropCreateDatabaseAlways
Custom DB Initializer
to choose from.
This makes me wonder, what does one do when they want to change the schema, but they want to keep the data they have?
I was just using sql directly, I could make temp tables, move stuff over, recreate the table with new columnns, move stuff back, etcv
What do you do when your classes and/or their relationships change in EF?
I think your looking for EF migrations:
https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/migrations/
for every schema change you create a migration, where you can add or remove tables or columns, or you can even run your custom script.
Each migration has an Up method, these will be applied if you run your migration, and a Down method this is used if you want to roll back to the previous migration for some reason.
With Update-Database you can apply all migrations, and with Update-Database –TargetMigration:{nameOfMigration} you can migrate to a specific version.
I've always used the edmx file approach and just run "update from database". Now i am using Code first from existing database.
When the DBA changes the database schema, how do I update my dbcontext file and POCOs to match? Is that what migrations are for? Do I just delete everything int he models folder and re-create?
"Code-First" has two different meanings in EF. It's both a Modeling workflow and a Mapping style. You can do Code-First Mapping with Database-First Modeling. You simply regenerate your entity types after changing the database, or change them manually to match the database change. This is what's called "Code-First From and Existing Database"
I Use code-first migration but I has error when run application.
error:Cannot find the object "dbo.Products" because it does not exist or you do not have permissions.
I have already got deleted Products table manually on sql server.I expect when Re-Run Project All table recreate if not exist in sql server.
In addition,I write 2 line for configure migration.
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
any help ?
If you are using migrations you shouldn't "manually" change the database. So now EF is generating code to remove the table for you, but it doesn't exist. Solution is to comment out the code in the Up() method that removes the table and update-database. See https://msdn.microsoft.com/en-US/data/dn481501
If you want your database recreated, you will need to switch to an initializer such as DropCreateDatabaseIfModelChanges. See http://www.entityframeworktutorial.net/code-first/database-initialization-strategy-in-code-first.aspx.
I have an existing database with data. I want to add code-first, non-automatic data migrations to the project.
My question is for the initial migration, should the initial migration be a snapshot of the current database schema or should it have empty Up() and Down() methods, essentially starting the migrations with the first schema change, when it occurs?
I can see the value in having the 1st migration being a snapshot of the existing schema. Just curious.
This?
PM> Add-Migration InitialMigration -IgnoreChanges
Or this?
PM> Add-Migration InitialMigration
I use Add-Migration InitialMigration and Up() contains all the CreateTable etc calls required to set up the initial database. Seed() menthos in the Configuration class adds any data required.
Question regarding Core Data migrations:
The original model was just a single entity (Transaction) with multiple properties. The app could store N Transactions, and display them in a table.
Original Core Data Model (simplified):
Transaction:
property_x
property_y
property_z
The model has now been changed so that the new top-level entity is a TransactionsList entity, with a 1-to-many relationship so that each TransactionsList has multiple Transactions.
New Core Data Model (simplified):
TransactionsList:
property_a
property_b
transactions <-->> Transaction:
property_x
property_y
property_z
<- transactionList
The model has now been changed so that the top-level entity is a TransactionsList entity, with a 1-to-many relationship (transactions) so that each TransactionsList has multiple Transactions.
I'm having a problem finding any examples (either in Apple docs, or on the web) of how to set up a migration from the original configuration to this new configuration.
Lightweight migrations don't seem to work (since this change involves adding a new relationship).
I set up a mapping file, and tried to create a custom migration policy, but if I set breakpoints on any of the functions in it, they are never hit.
I turned on migration debugging, and it indicates that the migration succeeded:
"Automatic schema migration succeeded for store at "..."
However, if I look at the internals of the sqlite database, there are no database entries for the TransactionsList entity, and all the transactionList fields in the Transactions (which should be linked to the owning TransactionsList) are null.
Two questions...
1) Any clues as to why my custom entity migration policy might not be getting called
2) Any suggestions on the best way to set up this kind of migration?
Thanks.
You are correct that a light-weight migration will not work. Further, a heavy migration would be very expensive computationally and I would not advise it.
I recommend a two step approach:
Allow a light-weight migration to occur. This will cause your TransactionList entity to be empty.
After the migration, walk through your transactions and create TransactionList entities as appropriate.
This will be faster and easier to test/debug than using a heavy migration. You can test to see if a migration needs to occur using the -[NSManagedObjectModel isConfiguration: compatibleWithStoreMetadata:] method. This will let you know a migration is needed, then you kick off the migration and finally do the post processing.