-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2. #96
Comments
sb-yb
changed the title
Feb 2, 2021
flyway.ignoreMissingMigrations
does not seem to work.flyway.ignoreMissingMigrations
does not seem to work on 4.0 or 5.2.
Looks like this is fixed in master but we are on play 2.6.x so 5.2 is the highest available version and that still has this issue. |
sb-yb
changed the title
flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2.
Feb 2, 2021
flyway.ignoreMissingMigrations
does not seem to work on 4.0 or 5.2.
FWIW this is fixed here: Any chance of getting this against play 2.6.x? |
sb-yb
added a commit
to yugabyte/yugabyte-db
that referenced
this issue
Nov 2, 2021
…t java package issue Summary: Also `ensureJavaFriendlyLocation` to workaround default being reserved keyword in java We will allow for adding java classes to db/migration/default_/common (Note the underscore) when dbName is default For `ignoreMissingMigrations` issue See [[ https://docs.google.com/document/d/1U_jEvOfTS3ofD-3NDL21soQxYxTu0pmdd-DEKZu_ynA/edit# | DB Migration Versioning Background ]] Our design options are limited to just Option#2 Use repeatable migrations for backport. This is very limiting and something we would like to get out of. We are specifically blocked by playframework/flyway-play#96 which has not seen any traction. At the same time we do not want to hand-roll our own flyway-play plugin and config mechanism mainly due to additional testing overhead. Also one day we will migrate to play 2.8.X and then we can upgrade to latest plugin with all the fixes we want. The code is identical to: org.flywaydb.play.PlayInitializer Only addition of ybPatchAdditionalConfigurations and ensureJavaFriendlyLocation methods that get called during configuring flyway. Rest of the classes are being used from plugin as-is Ideally could have used inheritance and not repeated even this class's code. Unfortunately all the interesting methods and properties needed to do what we want; were private. Test Plan: Unfortunatly resources in test path are not picked up by fakedbapp. So had to resort to manual testing. - Deleted V98 migration. - Got error - Disable flyway plugin and set `ignoreMissingMigrations=true` in `application.conf` - No error during startup. Reviewers: spotachev, sanketh, amalyshev Reviewed By: amalyshev Subscribers: jenkins-bot, yugaware Differential Revision: https://phabricator.dev.yugabyte.com/D13710
sb-yb
added a commit
to yugabyte/yugabyte-db
that referenced
this issue
Nov 4, 2021
…efault java package issue Summary: Also `ensureJavaFriendlyLocation` to workaround default being reserved keyword in java We will allow for adding java classes to db/migration/default_/common (Note the underscore) when dbName is default For `ignoreMissingMigrations` issue See [[ https://docs.google.com/document/d/1U_jEvOfTS3ofD-3NDL21soQxYxTu0pmdd-DEKZu_ynA/edit# | DB Migration Versioning Background ]] Our design options are limited to just Option#2 Use repeatable migrations for backport. This is very limiting and something we would like to get out of. We are specifically blocked by playframework/flyway-play#96 which has not seen any traction. At the same time we do not want to hand-roll our own flyway-play plugin and config mechanism mainly due to additional testing overhead. Also one day we will migrate to play 2.8.X and then we can upgrade to latest plugin with all the fixes we want. The code is identical to: org.flywaydb.play.PlayInitializer Only addition of ybPatchAdditionalConfigurations and ensureJavaFriendlyLocation methods that get called during configuring flyway. Rest of the classes are being used from plugin as-is Ideally could have used inheritance and not repeated even this class's code. Unfortunately all the interesting methods and properties needed to do what we want; were private. Original Commit: D13710 / 81d2902 Test Plan: Unfortunatly resources in test path are not picked up by fakedbapp. So had to resort to manual testing. - Deleted V98 migration. - Got error - Disable flyway plugin and set `ignoreMissingMigrations=true` in `application.conf` - No error during startup. Reviewers: sanketh, amalyshev, spotachev Reviewed By: spotachev Subscribers: jenkins-bot, yugaware Differential Revision: https://phabricator.dev.yugabyte.com/D13783
sb-yb
added a commit
to yugabyte/yugabyte-db
that referenced
this issue
Nov 17, 2021
…ation and default java package issue Summary: Also `ensureJavaFriendlyLocation` to workaround default being reserved keyword in java We will allow for adding java classes to db/migration/default_/common (Note the underscore) when dbName is default For `ignoreMissingMigrations` issue See [[ https://docs.google.com/document/d/1U_jEvOfTS3ofD-3NDL21soQxYxTu0pmdd-DEKZu_ynA/edit# | DB Migration Versioning Background ]] Our design options are limited to just Option#2 Use repeatable migrations for backport. This is very limiting and something we would like to get out of. We are specifically blocked by playframework/flyway-play#96 which has not seen any traction. At the same time we do not want to hand-roll our own flyway-play plugin and config mechanism mainly due to additional testing overhead. Also one day we will migrate to play 2.8.X and then we can upgrade to latest plugin with all the fixes we want. The code is identical to: org.flywaydb.play.PlayInitializer Only addition of ybPatchAdditionalConfigurations and ensureJavaFriendlyLocation methods that get called during configuring flyway. Rest of the classes are being used from plugin as-is Ideally could have used inheritance and not repeated even this class's code. Unfortunately all the interesting methods and properties needed to do what we want; were private. Original Commit: D13710 / 81d2902 Test Plan: Unfortunatly resources in test path are not picked up by fakedbapp. So had to resort to manual testing. - Deleted V98 migration. - Got error - Disable flyway plugin and set `ignoreMissingMigrations=true` in `application.conf` - No error during startup. Reviewers: spotachev, sanketh, amalyshev Subscribers: yugaware Differential Revision: https://phabricator.dev.yugabyte.com/D13976
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Added
db.default.migration.ignoreMissingMigrations=true
with no effect.I checked
PlayInitializer.scala
and it seems to map only few of the many flyway properties.Is there another way of setting this configuration?
I added
flyway.conf
to my resources folder with this config but did not help.The text was updated successfully, but these errors were encountered: