I have ASP.NET Project that have Entity Framework, it have its DbContext to map to their tables on DB.
Recently I added a model and perform a migration, but later I found that this project doesn't have any migrations, but have tables in DB.
So I created an initial migration with that new table, but is also including the other tables (because I had no previous migrations obliviously)
Since migrations are a requirement for this project and I cannot drop any table to start migration history from beginning, how can i safety perform a migration of my new table and keeping a right migration history?
I was thinking in to do something like this:
Delete the InitialMigration file that I created via dotnet ef add
Create a new InitialMigration with the current already created tables
(not sure how to do that) and somehow mark it as migrated.
Add the new model/table with another migration and update database.
Could you provide any help to achieve that?
Related
Last year, I rewrote a legacy application with .Net Core and EF Core, but elected not to add migrations at the time due to other limiting factors. The time has finally come where the new application can operate as the "single source of truth" for schema changes, but I'm at a bit of a loss as to the best way to move forward.
My end-goal is to have migrations that can scaffold out the entire existing database from nothing (minus the data contained within the non-lookup tables). Unfortunately, the most viable solution I've come up with so far is to build my migrations against a new, blank database. Then once the initial migration is created that matches the state of the current database, I would be able to copy over the __EFMigrationsHistory from the newly created database to the old one.
Alternatively, I can scaffold out a blank initial migration, and I could attempt to add logic in that migration to create the database from a SQL file if it did not exist.
Neither solution seems particularly "good". Aside from tools like FluentMigrator, are there any EF Core-centric approaches that can simplify creating migrations for an existing database that will need to be recreated for tests?
I had a similar issue when I wanted to squash all the existing migrations of the past 5 years (because it took forever to create a new instance). Here's how I did it:
Remove all migrations from your code, including any DbContextModelSnapshot.cs
Scaffold an initial migration: it will contain everything to create a new DB instance
Scaffold another migration, dedicated to seed the initial data (that's optional if you don't need to seed data on your newly created instance). The goal is to isolate the seed from the SQL structure.
Commit your changes
Keep the migrations, but remove the bodies of the Up and Down methods; the goal is to trick EF Core into thinking it applied those migrations
Update your existing instances with those empty migrations: nothing will be done, but the __EFMigrationsHistory table will contain them and ignore them in the future
Revert your changes, to restore the bodies of the migrations
With all those steps, you can now update your existing instances with any future migrations, yet also recreate new instances from scratch.
The project at the moment is using Database first approach, now we are switching to code first for various reasons.
using Scaffold-DbContext I have generated DbContext (we already have, but probably it will be less error prone) from one of dev environments where they are latest changes applied. Removed the copied .HasConstraintName(""); and .HasName(""); in .OnModelCreating() and I've created the Initial migration. So far so good.
The problem comes with updating existing database which is old compared to latest and as well keep the data.
What is the best way to update the database with the migrations?
I've added this in the Configure() method under Startup.cs to create the database if doesn't exists with the migrations, but not sure how to update old, existing one which doesn't have migration history table.
if (!context.Database.EnsureCreated())
context.Database.Migrate();
One solutions is to create an initial migration from your old database and put the MigrationId (example : 20200609075705_Initial ) manually into the dbo.EFMigrationHistoryTable.
After that you can add new migrations without any problem .
I have reverse engineered on existing database for code first. Next i Enabled-Migrating for the context (Code based migration). When i create an initial add-migration it works fine and would apply on an empty database.
But my requirement is that i need to use the same database i used for creating the models because of the data it has.
Now the conundrum is how do i implement the code based migrations. My database does not have a migration history table. So, when i run Update-database, it tries to create the existing tables and fails.
How can i capture the current state in the migration history or instruct EF to create the migration history with the current schema as the starting point.
Do i need to turn on the automatic migration for initial setup. Please suggest.
Note: I am using EF 6.
You need to establish a baseline migration of the existing items. So the first migration you create should be:
add-migration Initial -IgnoreChanges
The ignore changes tells EF to just save a snapshot of the current database. Now any subsequent migrations will not include the existing tables (just the changes). This would allow you to continue updating your existing database since EF will see the record in __MigrationHistory or deploy to a new, empty database.
See the under the hood section here.
I'm trying to connect my app to an existing Application.
So i created the Entities with the Entity Framework Database First.
It create all my entities and my Context that's fine.
But when i try to run it tell me that my migrations are not up-to-date so i tried to add-migration test to see what was missing...
It's creating all the table i asked it from DataBase First...
I cant recreate those tables i just want to be able to connect to those tables...
I absolutly need to connect to those tables, i cannot create a new one and i cannot clone the database.
How can i achieve this... i didnt find any resources on the subject that goes from the start to the end of the process.
Some help would be awesome!
The Problem: You can't reset migrations with existing tables in the database as EF wants to create the tables from scratch.
What to do:
Delete existing migrations from Migrations_History table.
Delete existing migrations from the Migrations Folder.
Run add-migration Reset. This will create a migration in your Migration folder that includes creating the tables (but it will not run it so it will not error out.)
You now need to create the initial row in the MigrationHistory table so EF has a snapshot of the current state. EF will do this if you apply a migration. However, you can't apply the migration that you just made as the tables already exist in your database. So go into the Migration and comment out all the code inside the "Up" method.
Now run update-database. It will apply the Migration (while not actually changing the database) and create a snapshot row in MigrationHistory.
You have now reset your migrations and may continue with normal migrations.
I'm testing with EF 4.3 (beta)
I have some new classes which should generate db tables and columns.
From a old project i have some old tables in my schema, which i want to access via EF.
All Classes are declared. For accessing the old table, there is a poco which is mapped.
The db migrations tries to create that old table, too.
How can it set that this class/table is not part of the migration, but part of the ef model?
xxx.OnModelCreating()
{
modelBuilder.Ignore<myOldTableClass>();
}
removes the entire class from model. finally i can't use it for access via dbContext.
i like to use automatic migrations.
i try to avoid to migrate old db tables completely to EF classes. (Yes, i know there are generators for that)
there are 120 tables, which are still used by an old applications.
some new tables which are only used with EF (new app).
there are 3 common used tables.
those should not created but accessed via ef.
With EF 4.3.1 released there is built in support for this scenario. When adding classes that are mapped to existing tables in the database, use the -IgnoreChanges switch to Add-Migration.
This will generate an empty migration, with an updated meta-data signature that contains the newly added classes.
Usually this is done when starting using EF Migrations, hence the "InitialMigration" name:
Add-Migration InitialMigration –IgnoreChanges
The correct workflow in this case is creating first migration prior to adding changes (new classes), than adding new classes and after that creating new migration where you will have only new tables.
If you didn't use migrations so far the framework will generate migrations for all tables you have in the project because it believes you are creating initial migration. Once you have migration generated you can modify its source file and remove CreateTable code for old classes from Up method. The problem is you will probably have to do this in any subsequent migration.
Edit: I wrote a walkthrough for adding migrations to existing project with EF 4.3.1