Modify migration 005 to tolerate the absence of river_migration - #465
Merged
Conversation
brandur
commented
Jul 22, 2024
| SELECT created_at, version | ||
| FROM river_migration_old; | ||
|
|
||
| DROP TABLE river_migration_old; |
Contributor
Author
There was a problem hiding this comment.
No actual changes here really, but everything moves up into the IF block/script above.
The down migration looks like it has more red because it already had a Pl/pgSQL block going on, and we only needed one of them, so I repurposed it to contain both conditionals.
brandur
force-pushed
the
brandur-005-tolerate-river-migration-absence
branch
from
July 22, 2024 04:52
8ba37a1 to
24e2676
Compare
Version 0.10.0's migration (005) brought in a number of changes including one that adds a new `line` field to the migration table. It works, but could present a problem for River installations that are purposely not using River's migration system, which is a path that even if not explicitly recommended, we've been trying to support. Here, add some conditionals to 005 so that the migration-related changes only run if `river_migration` exists. A test verifies that even if 001 (which brings in `river_migration`) had never run, the up and own migrations still work.
brandur
force-pushed
the
brandur-005-tolerate-river-migration-absence
branch
from
July 24, 2024 03:00
24e2676 to
2bd397b
Compare
bgentry
approved these changes
Jul 24, 2024
Contributor
Author
|
Thanks! |
brandur
added a commit
that referenced
this pull request
Jul 24, 2024
A small patch release containing #465 which will allow 0.10.0's migrations to be run more easily for users not using River's internal migration framework.
Merged
brandur
added a commit
that referenced
this pull request
Jul 24, 2024
A small patch release containing #465 which will allow 0.10.0's migrations to be run more easily for users not using River's internal migration framework. This will also require a separate CLI release which I'll follow up with.
brandur
added a commit
that referenced
this pull request
Jul 24, 2024
A small patch release containing #465 which will allow 0.10.0's migrations to be run more easily for users not using River's internal migration framework. This will also require a separate CLI release which I'll follow up with.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Version 0.10.0's migration (005) brought in a number of changes
including one that adds a new
linefield to the migration table.It works, but could present a problem for River installations that are
purposely not using River's migration system, which is a path that even
if not explicitly recommended, we've been trying to support.
Here, add some conditionals to 005 so that the migration-related changes
only run if
river_migrationexists. A test verifies that even if 001(which brings in
river_migration) had never run, the up and ownmigrations still work.