Home > Net >  flyway version migration issues from 6.3.1 to 8.5.x using docker container
flyway version migration issues from 6.3.1 to 8.5.x using docker container

Time:10-09

Team,

We have working flyway docker image (flyway community edition version 6.x) setup for postgresql 11.x version working. After upgrading our postgresql version to 14.x and now the existing flyway migration scripts (with updated community edition version 8.x) were failing with 'ERROR: Validate failed: Migrations have failed validation' error.

    - ingestionTime: 1665114622336
    message: Flyway Community Edition 8.4.1 by Redgate
    timestamp: 1665114621897
  - ingestionTime: 1665114622336
    message: 'Database: jdbc:postgresql://aws-rds-dev:5432/myapp (PostgreSQL 14.4)'
    timestamp: 1665114621898
  - ingestionTime: 1665114622336
    message: 'ERROR: Validate failed: Migrations have failed validation'
    timestamp: 1665114622186
  - ingestionTime: 1665114622336
    message: 'Detected applied migration not resolved locally: create trigger to update universal table. If you removed this migration intentionally, run repair to mark the migration as deleted.'
    timestamp: 1665114622186

Are there any document how we can migrate the version schema table entries if we upgrade the postgresql database?

Any help on this highly appreciated.

Thanks in advance..

CodePudding user response:

This is the result of a change introduce in Flyway V7. Before V7 missing repeatable migrations were ignored and didn't cause a validation error and after V7 they are no longer ignored

To resolve this and retain the previous behaviour you need to set ignoreMigrationPatterns="*:missing" which will prevent missing migrations from throwing a validation error. You can find the documentation for this parameter here

It's worth noting that missing migrations aren't ignored by default as it's not recommended to remove migrations as this affects the reproducibility of your database. If you did mean to remove the migration then running repair to mark it as deleted in the schema history table would be the preferred option

  • Related