For future visitors, this is a solution for DB specific sql, but applies to data loading too. https://flywaydb.org/documentation/faq#db-specific-sql You can set the flyway.locations=sql/common,sql/data property, and this can be set to different values with spring profiles(dev/test/prod), omitting the sql/data scripts on production.
The first rule is don’t. The second one is do it very carefully and use Flyway.repair() to realign the checksums in the DB with the ones on disk.
You can use the flyway.locations property. In test in would look like this: flyway.locations=sql/common,sql/derby and in prod: flyway.locations=sql/common,sql/oracle You could then have the common statements (V1__Create_table.sql) in common and different copies of the DB-specific statements (V2__Alter_table.sql) in the db-specific locations. An even better solution, in my opinion, is to have the same DB in prod … Read more
The title is somewhat contradictory, as the database is indeed not virgin as you installed, through the PostGIS extension, a number of objects in the public schema. You can either set flyway.schemas to a new schema, say my_app, which will then be created automatically by Flyway. Your application should then use this one instead of … Read more
Isn’t that what re-baselining would do? I’m still new to flyway, but this is how I think it would work. Please test the following first before taking my word for it. Delete the schema_version table. Delete your migration scripts. Run flyway baseline (this recreates the schema_version table and adds a baseline record as version 1) … Read more
Baselining a database at version V1_0__baseline.sql, for example, instructs Flyway to only apply migration scripts that have been created after V1_0. It does this by inserting a migration entry in the SCHEMA_VERSION table used by Flyway. When you run a migration, available migration scripts will only be applied if their version is higher than the … Read more