I'm creating a new code-first Web application but using the code from another application as a starting point. But I'd prefer to delete all the unneeded migrations from the new project.
Currently, my migrations look like this:
I'm pretty sure that I need to keep ApplicationDbContextModelSnapshot.cs and ApplicationDbContext.cs.
So here are my question is: Can I safely delete all the other migration files?
Note: There is no change I will want to revert migrations in the new application, so that is not a concern.
To summarize your question, you'd like to have a clean slate and not have all the migrations you've accrued over time polluting your migrations folder. I've often needed to do this myself when starting a new project and iterating a lot before being satisfied with my final schema.
The good news is that Entity Framework supports this natively out of the box, with just one caveat: if you ever hand-roll your own migrations (by calling Add-Migration and then editing the resultant migration file), perhaps to add a custom index for perf reasons, you'll have to make sure to recover those in this process.
All you have to do is delete your entire migrations folder (including the snapshot) and start over as though you were creating the project from scratch. Typically when you create your first migration, you've already defined a few entities (that's why you want to create the migration, after all); you're just taking that to the next level and want your entire database in that migration.
Once you've deleted your migrations folder, EF no longer thinks your project has migrations at all -- like I said, you're starting from scratch. So all you have to do is call Add-Migration [MigrationName] (i.e. Add-Migration InitialMigration) and it will scaffold the migration with everything needed to create your whole database.
Note: In my comments, I suggested you would need to call Enable-Migrations first, but that is evidently no longer necessary so you can just jump right into calling Add-Migration.
Why not just delete them and add an empty migration to check? If it breaks then you have your answer. Then just restore from version control.
But what Kirk Woll said is correct. Keep your ApplicationDbContext and add an intial migration.
Related
Environment: .NET Core 3.1 with EF Core
Short story: two migrations (A and B) were made. B is based on A. But update-database has not been executed for both A & B. A was deleted. Is there a way to revert A & B?
Long story: I think I did something stupid. I added a class in the code, then did add-migration (let's say it's migration A). After inspecting the generated migration class, I went back to make some changes. Because I haven't run update-database yet, I deleted migration A, then ran another add-migration, got migration B. Then I found out B is based on A. Deletion of migration A doesn't clear the migration.
Further research I found the migrations, even not updated to database, are kept in the MyDBContextModelSnapshot.cs file. Is that's how EF keeps track of it? I can't run update-database now because migration A is missing. Applying migration B will just cause an error in database.
My question is, instead of going into MyDBContextModelSnapshot.cs and manually revert it to before migration A and redo a migration, is there a way to fix this problem?
Thank you.
After some research, I simply executed this command to remove both A & B, even though the migration file of A has been deleted (and I didn't find it in recycle bin).
Remove-Migration
Then by using "add-migration" ef core created correct migration script.
Thank you.
The problem is indeed in the snapshot file, and you need to revert it to its state before A was added. Then you can add B and it will create all the new changes that were previously in A. This should do the trick even without the migration files:
dotnet ef database migrations remove B
dotnet ef database migrations remove A
dotnet ef database migrations add B
If it throws errors and you have source control this should also be a quick revert, if not, you should setup source control to prevent this type of thing. Committing early and often is a good practice for individual developers as well as teams, and it makes undoing mistakes trivial.
Finally, if the commands don't work and you don't have an earlier copy, you can use a previous migration. If you had a migration Z before adding A, you can copy the content of Z.Designer.cs to the snapshot (don't change the class name or imports). The migration designer is how EF tracks the changes, and it is applied to the snapshot when the migration is added. This is the same as manually reverting the snapshot, but less chance for error.
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.
Let's say I have a database which is created by three migrations. They can be seen in the table dbo._EFMigrationsHistory and the content could look like this:
MigrationId ProductVersion
20200516181941_InitialMigration 3.1.4
20200517091058_AddedIndexes 3.1.4
20200605115456_IntroducedBreweries 3.1.4
Now let's say that I for some reason lose all of the table (or just a part of it). So suddenly the table look like this:
MigrationId ProductVersion
20200517091058_AddedIndexes 3.1.4
20200605115456_IntroducedBreweries 3.1.4
And then I make a new migration, because i changed something in the database
Add-Migration SomethingChanged
This will work fine, since we aren't talking to the database at this point. But if I try to update the database, like this
Update-Database
It will fail, because it it trying to re-run the InitialMigration (or at least so I assume). So a common error is that the tables created in the InitialMigration cannot be created, because they already exist.
During development you can simply nuke the database and/or migrations, but that's not a very viable strategy for production. It can also be done with Script-Migration, which has a from/to option, allowing something like this:
Script-Migration 20200517091058_AddedIndexes 20200605115456_IntroducedBreweries
But this doesn't seem to work on Update-Database (not in the documentation either).
Is there any (production safe) way to fix this, so that the migration history isn't broken for all eternity?
The best way I can think of, is to manually insert the missing row(s) in the database, but this seems quite hack-ish...
The Issue: You have mucked up your migrations and you would like to reset it without deleting your existing tables.
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 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 have added around 100 migrations using Add-Migration in Package Manager Console and run Update-DataBase. Now I want to remove let's say 56th number migration. I have not found any way to do this. EF Core allows me to remove migrations sequences only, which is I think correct. because If I remove an in-between migration, later migration might fail due to dependency on old migrations. But If there is no dependency it should allow me to remove or disable.
I know my question can be invalid, But I'm asking just for the curiosity.
EF Core allows me to remove migrations sequences only, which is I think correct. because If I remove an in-between migration, later migration might fail due to dependency on old migrations.
Exactly.
But If there is no dependency it should allow me to remove or disable.
It's infeasible for EF Core to go through every migration and figure out if there is a dependency, especially for SQL statements.
How to remove a particular migration?
There's an answer to this though!
If you are sure there is no dependency, create an empty migration, then copy the "Up" and "Down" in the 56th migration into the opposite ("Down" and "Up") of the new migration.
This is what Git does too: to reverse an old commit, create a new commit that does the opposite.