Should I Delete Migration After Rollback

Should I delete migration after rollback

You should never change your old migrations. If you realised that given column is unnecessary, write a new migration to remove it.

The reason for this is so that you can restore database schema in any point of development. If you are working in a team, the fact that you removed the migration won't change your teammates' schemas. Even more, they have no migration to revert now!

How to rollback after delete a migration manually?

The migrations are stored to a table (called "migrations") in your database. When you run a migration, it is added to that table - using the rollback function looks at the latest migration in the table and runs the down() function for it.

If you reverse a migration manually (ie. deleting the table or columns that the migration created) but then try to use the rollback function, it will fail because the migration cannot remove columns / tables that have already been removed.

So the answer is to delete the migration(s) that you have reversed from the migrations table.

Is it safe to delete a .cs migration file after Remove-Migration and Update-Database

The purpose of Migrations is to incrementally update the database to match your new data models while preserving the existing content of the database.

You could even call it a form of version control for databases. For example, if you made a bad Migration, you can revert to the last Migration you are comfortable with.

CLI > dotnet ef database update MigrationToReturnTo
PMC > Update-Database -Migration MigrationToReturnTo

Therefore, although you can safely delete old Migration files, you potentially lose the ability to return to a previous schema for your database.

Please note that Entity Framework Core is notorious for having messy Migrations. I personally do not recommend removing Migrations unless you are sure you want to do a complete database reset.

If you run into issues about the database not being able to update due to records already existing, your best option is to completely delete your Migrations folder and the __EFMigrationsHistory table, and create a new initial Migration.

Which migration files can safely be deleted

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.

Mistake in an EF Migration better to rollback, delete, re-add or just simply add new

Migrations are just a tool to help you preserve data between schema changes. They're especially handy for managing multiple database servers like dev/test/production or dev-local databases in team environments.

If you only have one server, then rewriting a migration is cheap, so go ahead and correct it this way.

If everyone on your team has already applied the migration, or you've applied it to databases with data you would like to preserve, then it would be simpler to update the column using a new migration.

In other words, there is no right or wrong way to use Migrations, only a cost associated with rewriting history.

Safely remove migration In Laravel

I accidentally created a migration with a bad name (command: php artisan migrate:make). I did not run (php artisan migrate) the migration, so I decided to remove it.
My steps:

1. Manually delete the migration file under app/database/migrations/my_migration_file_name.php
2. Reset the composer autoload files: composer dump-autoload
3. Relax

---

If you did run the migration (php artisan migrate), you may do this:

a) Run migrate:rollback - it is the right way to undo the last migration (Thnx @Jakobud)

b) If migrate:rollback does not work, do it manually (I remember bugs with migrate:rollback in previous versions):

1. Manually delete the migration file under app/database/migrations/my_migration_file_name.php
2. Reset the composer autoload files: composer dump-autoload
3. Modify your database: Remove the last entry from the migrations table

---

Related Topics