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

flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2. #96

Open
sb-yb opened this issue Feb 2, 2021 · 2 comments
Open

Comments

@sb-yb
Copy link

sb-yb commented Feb 2, 2021

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.

@sb-yb sb-yb changed the title flyway.ignoreMissingMigrations does not seem to work. flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2. Feb 2, 2021
@sb-yb
Copy link
Author

sb-yb commented Feb 2, 2021

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 sb-yb changed the title flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2. flyway.ignoreMissingMigrations does not seem to work on 4.0 or 5.2. Feb 2, 2021
@sb-yb
Copy link
Author

sb-yb commented Feb 2, 2021

FWIW this is fixed here:
cf274a3

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
flyway/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
flyway/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
flyway/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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant