28

Is it possible to merge all migrations files into one ?

I created initial migration.

dotnet ef migrations add InitialMigration

Source

When ever I have some model change I create new migration update.

But now I have too many migration update files. Is ti possible to merge all migration files to one ?

Off course drop database is not an option, I have to preserve data !

Improve this question
3
  • 1
    Makes no sense, your database could be in ANY of the migration states. i.e if you have 6 migrations and your db is at migration 4,but if you merge merge 3 to 6 into one migration file, you can't never upgrade your db which is on the 4th migration Commented Nov 22, 2016 at 12:29
  • Best thing you could do is that if you have 15 migrations, rollback to migration 2, then create a new migration. But that still has problems above if your app runs on more than one server which are on different state (you can never roll back further than the oldest migration that is in use) Commented Nov 22, 2016 at 12:30
  • To address the concerns in the above comments, just bring all databases to the latest migration first. Then, delete all migration script files, including the model snapshot (important). I would then delete all records in the __EFMigrationsHistory table and add a new one that has the name of the single migration file you create. This is the way to preserve all data in all tables too. Commented Jun 29, 2023 at 14:59

5 Answers 5

Reset to default
48

EF 6.X has a option IgnoreChanges. That is the perfect fit for your scenario. But unfortunately it is not a feature available in EF core.

But there is a workaround.

Step 1 : Delete all the migration scripts in the Migrations folder.

Step 2 : In the package manager console : run

PM> Add-Migration InitialCreate

Step 3 : Delete both Up() and Down() methods code. Before you do this, keep those methods saved elsewhere as we will need them again in step 5.

Step 4 : run:

 PM> Update-Database

It'll insert a new record into __EFMigrationsHistory table.

Step 5 : After that fill the above migration script's (i.e. .._InitialCreate) Up() and Down() method from the content kept in a safe place from Step 3.

That is it. Now you have only 1 migration file :)

Note : EF core with Package manager console (PM) :Package Manager Console

Improve this answer
Sign up to request clarification or add additional context in comments.

12 Comments

This is not a good solution. It must clearly specify that this is a bad idea and should only be used in a test environment with caution prior to applying it to a production environment .
Instead of "Delete both Up() and Down() methods code" in step 3 you can just comment out the Up() method and then un-comment it in final step 5.
The best solution I used was working in database first (with edmx and/or database project). I didn't understand why Microsoft removed this option. More efficient (you can really fine tune your database for perfs), less issues when deploying to new server (just publish a database project to SQL server or generate a script to do that in 2 sec), EDMX model keep your code model and database in synch, ...
Db first is not gone per se. The EDMX visual designer was buggy and not really necessary. It's spiritual successor in EF Core is Scaffold-DbContext which beautifully reverse engineers entity models from an existing database's schema. This also makes it easy to go code-first from an existing database. If a database exists solely to serve an application, then code-first is the better option, particularly for deployment. Without code-first migrations, changes have to be made to the app and db separately when promoting to staging/production.
That approach seems to lose raw SQL statements like migrationBuilder.Sql() used within Up() or Down()
|
9

When you want to merge not all but N last migrations, the protocol is not the same:

  1. Revert N last migrations, one by one, each with the 2 following commands:
    • dotnet ef database update NameOfTheLastMigration
    • dotnet ef migrations remove
  2. Apply reverts to database:
    • dotnet ef database update
  3. Create the "merge" migration:
    • dotnet ef migrations add NameOfTheMergeMigration
Improve this answer

1 Comment

Reverting will delete all columns you have added, including the data in them.
6

One way to do that is removing all migration files physically and adding new one. If your migrations are in "Migrations" folder, you can simply delete it, otherwise you need to delete your "ModelSnapshot" file too. I think this approach can solve your issue.

Improve this answer

1 Comment

You also need to empty the _EFMigrationsHistory table and add single row with the name of the new migration, or else the next time you apply migrations it will try to re-create all of your tables. (It will fail, so no data should be lost.)
3

This is what I find the most efficient and easier way to do it:

  1. Apply the last migrations if not already.
  2. Remove all rows from the _EFMigrationsHistory table from your database
  3. Remove the Migrations folder from your project.
  4. Create a new Migration either with package manager console or dotnet ef cli
  5. Copy the name of the Freshly created migration (Without extension) and insert it as a new row in the _EFMigrationsHistory table along with your dotnet ef tool version.
Improve this answer

2 Comments

This seems like the simplest option to get the Migrations folder cleaned up, assuming you don't mind doing a couple simple SQL operations.
@Matt Yes, I wonder if anyone has created an automation tool for this.
2

As a fellow .NET C# developer I concluded that EF migrations were rather poorly designed to interface with source control as they store large binary schema data per migration (bad for source control systems) and cause unending grief when trying to merge migrations from multiple GIT branches (bad for team workflow). So I eventually ditched EF migrations and replace them with something much simpler that would also work with both GIT merges and our DBAs (who only cared for SQL).

I chose the FOSS app MyBatis / Migrate that works with any JDBC supported SQL engine. I've used it with SQL Server, MySQL and Oracle (not Postgres yet). I've also used it with C# / EF projects (I just stopped using EF's migrations). It's a no-brainer so great for novice coders. No dependencies so ok to use for any SQL database project with any application language. Since it's pure SQL you can leverage features specific to your SQL dialect (e.g. In MySQL, you can add a new column after any existing column using the MySQL specific AFTER clause rather than be forced to add it at the end of the table).

You just create timestamped SQL scripts (using their migrate new command) that contains both forward and rollback SQL code for your schema or data migration. Using filenames prefixed with timestamps (instead of version numbers) means your software teams can easily create and later merge multiple migrations files from different git branches - too easy! They just get combined and applied to the database as part of a single release. If you do need to perform complex data migrations you can either code a stored procedure OR you can code a Java class as part of a migration (although this won't help your DBAs).

For DBAs who don't want to deal with VS or .NET, you can use the migrate script command to generate either a forward or rollback SQL script that gathers the sequence of migrations to be applied to a given software release.

You can configure multiple database instances (e.g. development, test, stage, prod) and just select which one you want to apply your SQL migration to using the --env option (e.g. --env=stage). In each database instance it creates a CHANGELOG table that tracks the migrations that have been applied.

To get started ... Install Java JDK 8 and then install this app.

Examples:

$ migrate status   #  Shows migrations applied and "pending" (be applied) to the selected database 
$ migrate up 1     # Applies the next migration
$ migrate down 1   # Undo the last migration 

$ migrate redo 1   # Undo and apply last migration (handy when developing migrations)

$ migrate up       #  Applies all pending migrations 

$ migrate --env=test status   # Show status of the `test` database.

# Emit forward and reverse SQL for a sequence of migrations. 
# Just what your DBAs wanted!
$ migrate script 20090804225207 20090804225333 > up.sql    
$ migrate script 20090804225333 20090804225207 > down.sql

Video thumbnail
MyBatis Schema Migrations on YouTube

If you'd prefer to stick with C# code you might want to have a look at Fluent Migrator. It's particularly good for product projects where you need to support multiple database platforms. I've used it project that supported both SQL Server + MS-Access.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.