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 !
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
When you want to merge not all but N last migrations, the protocol is not the same:
Revert N last migrations, one by one, each with the 2 following commands:
dotnet ef database update NameOfTheLastMigration
dotnet ef migrations remove
Apply reverts to database:
dotnet ef database update
Create the "merge" migration:
dotnet ef migrations add NameOfTheMergeMigration
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.
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.
https://mybatis.org/migrations/
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
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.
Related
I'm migrating an API from .NET Framework 4.7 to .NET 6 (including EF to EF Core) and when I create the dbContext and execute the Add-Migration command, it creates the whole structure of the database, which I'm scared of running because I'm not sure what could change.
Is this behaviour normal? Is there any way to avoid this "initial migration" or check beforehand if this migration causes any issue on the database?
Thanks.
That's correct behaviour, EF Core migrations should be able to create full DB schema when called on an empty DB, so Add-Migration generate initial migration which will do exactly so (all existing EF4.7 migration won't be available for your EFCore 6 program).
At the same time, that initial migration will fail on existing DB because it already has all tables/columns/views.
Solution here is following: add code to the beginning of migration which checks whether one of the tables already exists:
If yes, than DB structure is already match initial migration, nothing to do here (just exist)
If not, this is blank DB and initial EFCore migration should be ran.
Here how check table existence inside migration: https://entityframeworkcore.com/knowledge-base/53473747/check-if-a-table-exists-using-ef-core-2-1
We have a EF project with multiple migrations being applied almost weekly to our database. I have to remove and add a new migration because I made a typo in a property of a model and I need it to be re-created.
I followed the usual steps:
dotnet update database MOST_RECENT_CORRECT_MIGRATION -c CONTEXT_NAME
dotnet ef migrations remove
The last command should revert model snapshot changes and delete the migrations cs and designer.cs files, but instead it only reverts the model snapshot and it doesn't deletes the previous migration. Until a few migrations back it worked perfectly and I was able to follow this workflow and recreate migrations that needed naming changes and more from the PRs. I can delete the migration manually and try to come up with a working new migration but I don't want to break things in the background and I want to do things properly.
When I run it with verbose I get (among the usual enormous amount of messages) the following message that looks not good:
[...]
A manual migration deletion was detected.
[...]
Does this have anything to do with the problems I'm having? Should I just delete all the changes and recreate a new migration from, say, the last moment it worked fine?
I'm using .NET Core 3.1 and SQL Server.
I can also move on a create a new migration that drops the wrongly typed column and replaces it with the new, correct one.
I'm developing a WPF app utilizing a SQL Server Compact 4.0 database. For the course of this project, we made several changes in the model structure with a number of code-based and later with automatic migrations. They all are stored in the _MigrationHistory table and represented by several migration classes.
Now it appeared that I need to considerably change the model. Since the app is still in the development phase, dropping data in the database is not a concern. I would like to get rid of the whole previous migration history and start a new clean model. So my question is what steps are to remove the whole history of migrations and start a new history with automatic migrations in the future.
What parts of the project must be deleted and how to do it safely?
First Make sure your project is backed up and your database is also backed up. In case something goes wrong.
If your project is setup using entity framework code first,
In the project you can delete all the migration files in the 'Migrations' folder except 'MigrationConfiguration.cs' contained within the project that is using entity framework.
Also if you are not concerned with dropping the database, then go-ahead and delete the entire database, then create a new one with the same name that is configured in your database context connection string found in your project's config file.
Rebuild your solution and create a new migration by typing the command in the package manager console 'add-migration' and provide a name. This will create a new migration to create the database for all your code first models. If the generated migration file looks correct, then run 'update-database' in the package manager to apply the migration to your empty database.
I am thinking of using Entity Framework 6 Code First for database interaction alongside DbUp for database schema update. The thing is I don't want to use EF migration for reasons. So, the workflow that I've reached to is:
Change model (add POCOs, alter properties, etc)
Run Add-Migration temp_file in Visual Studio Package Manager Console
Run Update-Database -Script in Visual Studio Package Manager Console
Grab the generated sql scripts including insertion of new row in table __MigrationHistory
Create a new .sql file and past the generated scripts
Delete temp_file
Run DbUp
It works perfectly locally and on production server, however I don't feel comfortable with adding and then deleting temp_file every time a new migration is generated (I wish there were a way to permanently stop temp_file being added to the solution.).
So question:
Is there a better way to do database migration with DbUp using Entity Framework?
In most of the cases you can skip steps (2) and (6) by utilizing the Automatic Code First Migrations:
Automatic Migrations allows you to use Code First Migrations without having a code file in your project for each change you make.
By default automatic migrations are disabled. You enable them by adding the following like in your db migration configuration class constructor (usually called Configuration and located under Migrations sub folder):
AutomaticMigrationsEnabled = true;
Some things to consider:
Documentation states that automatic migrations have limitations, so be aware.
You can mix automatic and code based migrations (in other words, the proposed and your current approaches).
The benefits of your current approach is that you can preview how EF interprets your model changes and also add/remove/change parts of the migration code.
The automatic migrations have been deprecated (don't exist) in EF Core, so in EF Core projects you have to use something similar to your current approach, except that you have to keep the generated migration code files.
Maybe this answer is too late, but maybe it will be useful as well. I completely understand your approach to use Entity Framework as ORM and a different tool for schema migration. But choosing DbUp requires you to write manually SQL or generate them as you described above. I suggest considering to use FluentMigrator instead of DbUp. It follows the same philosophy, but allows writing migration steps in C# using fluent syntax. In addition, it supports downgrades, i.e. rollback.
Here is an example:
[Migration(1)]
public class CreateUserTable : Migration
{
public override void Up()
{
Create.Table("Users");
}
public override void Down()
{
Delete.Table("Users");
}
}
I am working on a entity framework project generating the Entity classes using the New-> ADO.NET Entity Data Model -> Code First From Database. I then select nearly 100 tables to generate (not all tables are suitable to go in the model).
Problem is I am regularly updating the schema, and the only way to refresh the model seems to be to delete and start again, which is fine except I have to re-select the nearly 100 tables again.
Is there any easy way of scripting this generation process?
You should look into using Entity Framework Migrations and start doing your schema changes from the code itself
Set the CompanyName.ProjectName.Infrastructure.EfRepository (the project which has your DbContext) as start up project of the solution
Open the Package manager console
Choose CompanyName.ProjectName.Infrastructure.EfRepository as default project
Run the following commands:
Enable-Migrations -ConnectionStringName "EfDataRepository"
Add-Migration Initial -ConnectionStringName "EfDataRepository"
Update-Database -ConnectionStringName "EfDataRepository" -Script -SourceMigration:0
Then delete the auto-generated Migrations folder within the EF project!
Where EfDataRepository is the connection string name.