ignoreMissingMigrations for aggregated scripts
jbottinger
Posts: 2 New member
I have a java project with various modules that contain entity models. For simplicity, let's call them "model1", "model2", "model3", and so forth.
There are various other modules that import these models in varying combinations: module1 might include model1, module2 might include model1 and model2, module 3 might ONLY include model3, module might include all three models.
What I'd planned to do was:
put db/migrations/V1_create_table_model1.sql in model1
put db/migrations/V2_create_table_model2.sql in model2
put db/migrations/V3_create_table_model1.sql in model3
That way, each SQL script would be executed in order. Naturally, flyway complained that v1 was missing for module 3.
There was an ignoreMissingMigrations flag, but that's deprecated and gone, and I don't think I understand how to replicate the behavior without it. I also need to anticipate model1 eventually getting V5_update_special_data.sql eventually because each model needs its own migration history without clashing with the other models.
Any advice on how I can accomplish this?
There are various other modules that import these models in varying combinations: module1 might include model1, module2 might include model1 and model2, module 3 might ONLY include model3, module might include all three models.
What I'd planned to do was:
put db/migrations/V1_create_table_model1.sql in model1
put db/migrations/V2_create_table_model2.sql in model2
put db/migrations/V3_create_table_model1.sql in model3
That way, each SQL script would be executed in order. Naturally, flyway complained that v1 was missing for module 3.
There was an ignoreMissingMigrations flag, but that's deprecated and gone, and I don't think I understand how to replicate the behavior without it. I also need to anticipate model1 eventually getting V5_update_special_data.sql eventually because each model needs its own migration history without clashing with the other models.
Any advice on how I can accomplish this?
Tagged:
Answers
I'm not sure ignoreMissingMigrations is what you need; it would have allowed flyway to continue if formerly applied migrations were missing.
Whereas your implementation sounds more like you want to be selective about which migration are run against which targets. Depending on your preferred architecture, I'd recommend one of two approaches.
1. Keep your different entity models in different directories, independent of one another, they then can be executed in sequence. Because they are independent nothing is missing. This may result in duplicate files on disk, thought that may be a serviceable trade-off.
2. Environment specific config files
This would allow you to define in your migrations what targets they should be applied to. This would require more time and effort on your part but no file duplication.
Footnote:
If you are looking for the functionality of ignoreMissingMigrations for other reasons, it's been superseded by the more flexible ignore-migration-patterns option which will afford you the same capability.