Closed acaloiaro closed 8 months ago
Since you're embedding the migrations at build time, you could determine what the "latest" migration version is based on the files in that embed. If the version in the DB is greater than that you could start with raising a log message at the very least. But for an older version to know how to downgrade from a migration it doesn't have might be tricky.
Rollbacks might be pretty tricky, unfortunately.
I wonder if this issue can be addressed with a release policy that mandates 2-phase release for all migrations.
down
migration is released up
migrationObviously not perfect, but it allows the existing migration tooling to be used. Maybe it's a start of something.
Obviously users would still be able to "revert" back by multiple versions, which could skip the release with the down
migration. :thinking:
Closing since migrations change so infrquently
Currently
up
migrations are run when neoq starts. In order to roll back to previous releases, users need to be able to "roll back" theirneoq_jobs
schema to previous versions.Currently, there is no way to specify which schema version the the current version of neoq should use.