Rollback support

[IndikaUdagedara]

It would be great to have a rollback feature so that the schema can be rolled back to a specific migration. The functionality could be similar to EF migrations rollback.

Here's the intended functionality:

Assume there are 4 migration scripts 1.1, 1.2, 1.3, 1.4

When migrate command is executed with a specific version e.g. 1.3 all migrations greater than that (1.4) will be rolled back by executing the corresponding rollback script. This means, in addition to the migrations directory, users need to provide a rollback directory with the rollback scripts (Similar to Up() and Down() methods in EF).

This functionality will be similar to EF Update-Database command.

[lecaillon]

@indikaudagedara Thanks for the feedback. Appreciate it.

I know EF, Flyway and others have that sort of feature. But I can not see a real use case for it. Can you give me an example please ?

[IndikaUdagedara]

Thanks @lecaillon

The use case is actually to get the db back to a stable state after a faulty migration. E.g. migration 1.4 broke something (although got successfully applied) so need to revert back to 1.3. I guess this could be achieved by rolling forward i.e. deploying a new 1.5 script to revert the changes in 1.4 but having a rollback feature would make it convenient for CI/CD. The steps would be

• Run migration x
• Run tests
• If tests fail revert x, otherwise mark the deployment as success

[amiralgazi]

@lecaillon Is there any update related to this?

At the company I work for, I develop a .Net Core tool using Evolve, as part of our CI/CD project. It is going to be finished soon. Thus, a rollback feature is extremely important to us.

We could offer payment, if needed.

Please let me know what the plan is

[lecaillon]

In your opinion, what should be the behavior of Evolve in this case ?

Assume there are 4 applied migrations: V1.1, V1.2, V1.3, V1.4 And only 1 undo migration: U1.3 Is it allowed to rollback to V1.2 without a U1.4 script?

Is it the responsability of the user to know what is ok or not, or Evolve should only accept to rollback to a version where all the undo migration are defined ?

[IndikaUdagedara]

We found DB migration rollbacks is problematic (although it sounds a nice feature). We ended up with

• ensuring database changes are always backward compatible
• rolling forward i.e. instead of rolling back a previous one, create a new migration with

[lecaillon]

Thanks for the feedback @IndikaUdagedara It is very interresting. Indeed I had already heard of that issue. I keep that in mind for that feature.

[mfedatto]

I'm looking forward to such feature too. I believe rolling forward, like @IndikaUdagedara said, is the way to go. I use to create my rollback scripts on a separated directory, not listed in Locations, and if needed I just move it to be rolled out forward on a new version.

[kellielellie1]

Rolling forward not so easy to do when you embed the scripts. That would involve another deployment.

[Lothrandir]

If you ever consider to actually support rollback i suggest looking at pop/soda (https://gobuffalo.io/en/docs/db/toolbox, https://github.com/gobuffalo/pop). All migrations have an up and a down migration by default. When testing locally it is pretty convinient to just migrate down the migration you just made that you want to change. We have not had any situations where we use it in production.

[madison-tobal-shift]

Hey guys it would be indeed great to see this feature. My use case is a continuous deployment pipeline, where for every deployment we want to be able to deploy the binaries with database changes but also rollback the database schema if the application goes back one version. It would be good to rollback up to a specific point: per example if I use rollback V_3.sql, it would undo the migrations backwards until V_3.sql There's this tool, dbmate, that we use for clickhouse that in each .sql file it includes a migrate part and another rollback part (two sections) so the tool know which one to apply when needed: https://github.com/amacneil/dbmate

[vish9812]

You can have 2 files v1_1__CreateTable.up.sql and v1_1__CreateTable.down.sql. Now, you can throw error if up and down files don't match which would make it more robust and reliable. And people who may need only up can pass a flag like --no-rollback.

The up migrations would run as usual in ascending order and the down will run in descending order.