Support out of order migrations

[RoryQ]

What

Similar to FlywayDB outOfOrder option.

Allows migrations to be run "out of order".
If you already have versions 1 and 3 applied, and now a version 2 is found, it will be applied too instead of being ignored.

Why

Flexibility to apply a hotfix to production, then cherry-pick the migration back to development environments which are already ahead of production.

[110y]

@RoryQ

So sorry for late responding.

Flexibility to apply a hotfix to production, then cherry-pick the migration back to development environments which are already ahead of production.

It's interesting case which I've not thought so far.
In my case, I'm always apply migrations for development environments first even though it's for the hotfix.

Could you explain more specifically about the use case?

[RoryQ]

Yep, so to elaborate on the hotfix example. Consider the following timeline.

Release goes to production with a large table
migrations: ["001_create_large_table.sql"]
Production Version: 1

Development has already started and changes have been applied for new tables
migrations: ["001_create_large_table.sql", "002_new_feature.sql", "003_another_feature.sql"]
Development Version: 3

Then when users complain of slowness, or a critical bug is found. Then a hotfix is required for production. But what version number do we choose for the hotfix? If we choose 2:

migrations: ["001_create_large_table.sql", "002_hotfix_urgent_issue.sql"]
Production Version: 2

Then when we merge the hotfix back into the development environment then we have a clash between 002_new_feature.sql and 002_hotfix_urgent_issue.sql

So what if we anticipate the hotfix version in develop and choose 4?

migrations: ["001_create_large_table.sql", "004_hotfix_urgent_issue.sql"] Production Version: 4`

migrations: ["001_create_large_table.sql", "002_new_feature.sql", "003_another_feature.sql", "004_hotfix_urgent_issue.sql"]
Development Version: 4

Then the development environment works. But then there's a problem when we go to release these changes to production. The Version is now 4, migrations 002_new_feature.sql and 003_another_feature.sql won't be applied!

So the alternative is to apply the hotfix to the development environment as you said, then apply all those changes to production. This requires the migrations in the development environment to be backwards compatible with the production app code, and in a production ready state.

Having the flexibility here to apply only the hotfix to production and the remaining migrations at the appropriate time would be beneficial as it relives the burden of testing and verifying the out of scope migration scripts.

[RoryQ]

Hi, any update on this?

I have other improvements in my fork that I think the wider community will benefit from. I think it's best for the community if these improvements are available at the "source", avoiding unnecessary fragmentation.

Do you have concerns with the implementation? Or do you need help maintaining this project?

[jchamb]

Curious if there are updates here? I saw @RoryQ's original PR was simply closed without any reasoning. I didn't see anything in release notes that suggests this is actively supported.

Use case is identical to what @RoryQ outlined above.