Comments
1 comment
-
I've tried this on v 11.3.4 and it seems to do what you expect already, are you using a very old version of Flyway ? …
Setup
- 1 versioned migration
- 1 repeatable migration
Both have been deployed (migrated) and both subsequently updated:
Run flyway validate
ERROR: Validate failed: Migrations have failed validation Migration checksum mismatch for migration version 1 -> Applied to database : -690524359 -> Resolved locally : 1020942798 Either revert the changes to the migration, or run repair to update the schema history. Detected outdated resolved repeatable migration that should be re-applied to database: my repeatable. Run migrate to execute this migration. Detected resolved repeatable migration not applied to database: my repeatable. To fix this error, either run migrate, or set -ignoreMigrationPatterns='*:pending'. Need more flexibility with validation rules? Learn more: https://rd.gt/3AbJUZE
Run flyway repair
Repair of failed migration in Schema History table "main"."flyway_schema_history" not necessary. No failed migration detected. Repairing Schema History table for version 1 (Description: nothing, Type: SQL, Checksum: 1020942798) ... Successfully repaired schema history table "main"."flyway_schema_history" (execution time 00:00.044s).
Run flyway migrate
Successfully validated 3 migrations (execution time 00:00.034s) Current version of schema "main": 1 Migrating schema "main" with repeatable migration "my repeatable" +---+ | 1 | +---+ | 1 | +---+ Successfully applied 1 migration to schema "main" (execution time 00:00.003s)
Add comment
Please sign in to leave a comment.
Flyway repair updates checksum for all the records in schema history where it finds a checksum mismatch including Repeatable migrations.
While this behaviour is correct for version migrations.
Having this behaviour for repeatable migration leads to the latest checksums being applied in the existing schema_history entries, as a result these repeatable migrations do not get executed on the next invocation of Migrate
Repeatable migrations should not have this behaviour, for repeatable migrations only the failed entry should be removed as part of Repair operation, the check-sum of existing records should not be affected.