Fix report_card.collection_preview in v49
#42950
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
johnswanson
added
the
backport
|
noahmoss
approved these changes
May 21, 2024
johnswanson
added
no-backport
|
I'm manually backporting this here |
This is a bit painful. I merged this change, but realized we need to backport the fix to v49. However: - we don't want to have two versions of the migration (one with a v49 id, one with a v50 id) because then if someone upgrades to 50, then downgrades to 49, the `rollback` will run and change the type back, leading to a bug. - we don't want to push a v51 changeSet ID to v49 or v50, because we give the user a helpful notice when their database needs a downgrade. We do this by checking for the latest *executed* migration in the database and comparing it to the latest migration that Liquibase knows about, and making sure the executed isn't bigger than the known (e.g. you can't have executed a v51 migration if it isn't in the local migration yaml). That would all work fine, except that then we want to tell you how to downgrade your database, and we use the latest-executed version for that. So if, for example, someone upgraded from 48 to 49 and got a v51 changeset, then downgraded back to 48, they would get an error telling them to run the *v51* jar to roll back their DB. In this case though, I think it's fine to just move the migration around to v49, then we can backport it to 49 and 50.
johnswanson
force-pushed
the
jds/correct-type-on-collection-preview-redux
branch
from
7de4ac6
to
05734a3
Compare
|
@johnswanson Did you forget to add a milestone to the issue for this PR? When and where should I add a milestone? |
oisincoveney
pushed a commit
that referenced
this pull request
May 22, 2024
This is a bit painful. I merged this change, but realized we need to backport the fix to v49. However: - we don't want to have two versions of the migration (one with a v49 id, one with a v50 id) because then if someone upgrades to 50, then downgrades to 49, the `rollback` will run and change the type back, leading to a bug. - we don't want to push a v51 changeSet ID to v49 or v50, because we give the user a helpful notice when their database needs a downgrade. We do this by checking for the latest *executed* migration in the database and comparing it to the latest migration that Liquibase knows about, and making sure the executed isn't bigger than the known (e.g. you can't have executed a v51 migration if it isn't in the local migration yaml). That would all work fine, except that then we want to tell you how to downgrade your database, and we use the latest-executed version for that. So if, for example, someone upgraded from 48 to 49 and got a v51 changeset, then downgraded back to 48, they would get an error telling them to run the *v51* jar to roll back their DB. In this case though, I think it's fine to just move the migration around to v49, then we can backport it to 49 and 50.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bit painful. I merged this change, but realized we need to backport the fix to v49. However:
we don't want to have two versions of the migration (one with a v49 id, one with a v50 id) because then if someone upgrades to 50, then downgrades to 49, the
rollbackwill run and change the type back, leading to a bug.we don't want to push a v51 changeSet ID to v49 or v50, because we give the user a helpful notice when their database needs a downgrade. We do this by checking for the latest executed migration in the database and comparing it to the latest migration that Liquibase knows about, and making sure the executed isn't bigger than the known (e.g. you can't have executed a v51 migration if it isn't in the local migration yaml). That would all work fine, except that then we want to tell you how to downgrade your database, and we use the latest-executed version for that. So if, for example, someone upgraded from 48 to 49 and got a v51 changeset, then downgraded back to 48, they would get an error telling them to run the v51 jar to roll back their DB.
In this case though, I think it's fine to just move the migration around to v49, then we can backport it to 49 and 50.