Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow --target-version to revert migrations with -f/--force flag #3727

Closed
Tortoaster opened this issue Feb 7, 2025 · 1 comment
Closed
Labels
enhancement New feature or request

Comments

@Tortoaster
Copy link

I have found these related issues/pull requests

Relates to #2538

Description

sqlx migrate run --target-version [version] is only allowed to apply up migrations, and will give an error if the target version is older than the latest applied migration. Likewise, revert is only allowed to apply down migrations; there is no command that migrates to a specific version regardless of the current version of the database.

I'm working on a Helm chart that deploys an application that requires a database. An init container first fetches the complete list of migrations, and runs those migrations up to the required version with a superuser account, after which the application itself can run with fewer privileges. This works great, but Helm charts can also be rolled back to previous versions, and while this isn't super common, doing so will likely break the application if the database isn't rolled back properly as well. I cannot expect users to revert the migrations manually, but I do want to support rollbacks, so it would be useful if the init container could revert migrations as well.

Prefered solution

A -f/--force flag that allows sqlx migrate run --target-version [version] to apply down migrations if necessary.

In the meantime, I can apply both sqlx migrate run --target-version [version] and sqlx migrate revert --target-version [version], knowing that one of them will return an error.

Is this a breaking change? Why or why not?

The new functionality only applies when using a previously non-existent flag, and supplying non-existent flags to the CLI will currently throw an error, so it's not a breaking change.

@Tortoaster Tortoaster added the enhancement New feature or request label Feb 7, 2025
@Tortoaster
Copy link
Author

On second thought, the workaround works well enough!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant