Hack a flywayPrefixToMigrationScript other than db/migration?

[chadwhitacre]

Greetings! ☺️

I would like to keep my migrations in conf/schema/sql rather than in conf/db/migrations (because I also have a conf/schema/json and I want them to be parallel). Can I accomplish this with flyway-play as it stands today?

My best attempt so far is this config:

db.data.driver = org.postgresql.Driver
db.data.migration.schemas = ["myschema"]
db.data.migration.initOnMigrate = true
db.data.migration.auto = true
db.data.migration.locations = ["../../../schema/sql"]

Which gives me this log output:

2018-08-16 16:26:02 -0400 [WARN] from org.flywaydb.core.internal.util.scanner.classpath.ClassPathScanner in ForkJoinPool-1-worker-1 - Unable to resolve location classpath:db/migration/data//////////schema/sql
2018-08-16 16:26:02 -0400 [INFO] from org.flywaydb.core.internal.command.DbSchemas in ForkJoinPool-1-worker-1 - Creating schema "myschema" ...
2018-08-16 16:26:02 -0400 [INFO] from org.flywaydb.core.internal.metadatatable.MetaDataTableImpl in ForkJoinPool-1-worker-1 - Creating Metadata table: "myschema"."schema_version"
2018-08-16 16:26:02 -0400 [INFO] from org.flywaydb.core.internal.command.DbMigrate in ForkJoinPool-1-worker-1 - Current version of schema "myschema": null
2018-08-16 16:26:02 -0400 [INFO] from org.flywaydb.core.internal.command.DbMigrate in ForkJoinPool-1-worker-1 - Schema "myschema" is up to date. No migration necessary.

My hunch is that this would require some changes to flyway-play but I figured I would pose the question!

[tototoshi]

I think your attempt is good enough. I will consider making it configurable in application.conf if more requests are received from others.

[nikitaDanilenko]

I second the request.

On a related note: The description on the start page seems to indicate that you can either supply a scriptsDirectory or locations, when in reality, the locations can be combined with the locations. Hence, if I want to have multiple databases that have the same structure and use the same pool of migrations, I can do the following:

1. Create db.migration.default.common for all migrations
2. Create db.migration.default.testdata for testing purposes
3. Configure the migrations so that they use both, the scripts directory and the locations parameter

db.default.migration.scriptsDirectory="default"
db.default.migration.locations=["common"]

db.otherThanDefault.migration.scriptsDirectory="default"
db.otherThanDefault.migration.locations=["common", "testdata"]

I think that it would be helpful, if the description on the main page provided this information.

Having the option suggested by the OP would greatly help in this case.

Best regards,

Nikita