Prefix and Separator for Java-Migration Files
See original GitHub issueSupport Prefix and Separator for Java-Migrations.
For Example:
Flyway flyway = new Flyway();
flyway.setJavaMigrationPrefix("V1_");
flyway.setJavaMigrationSeparator("_-_");
Issue Analytics
- State:
- Created 8 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Flyway by Redgate • Database Migrations Made Easy.
Flyway discovers SQL-based migrations from one or more directories referenced by the locations property. Unprefixed locations or locations with the classpath: ...
Read more >One-Stop Guide to Database Migration with Flyway and ...
A comprehensive guide for database migrations using Flyway with and without Spring Boot.
Read more >Using Flyway - Quarkus
The file name prefix for repeatable SQL migrations. Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix ...
Read more >Configuration (flyway-core 7.3.2 API) - javadoc.io
The file name prefix for versioned SQL migrations. java.lang.String, getSqlMigrationSeparator(). Retrieves the file name separator for sql migrations.
Read more >How to remove prefix from Flyway migration name?
sql-migration-prefix: "" with the same file format as yours and it worked. Could you elaborate more on your resource path, usage, and stack ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@MikielAgutu not quite - the desired behaviour would be to have short running and long running migrations - all of the short running migrations would always run before the long running migrations.
It’s so we can fail a build if the short running migrations fail and then run the long running migrations in a detached mode.
In the end we were able to live without the behaviour by running everything in detached mode (which looking back at the initial comment we should blog about).
I’ve also just realised based upon your comments that the tool already supports this. Nothing prevents us from invoking flyway twice programatically with different migration locations - thanks for taking the time to get back to me!
This issue is quite old so I’m not sure it’s still relevant.
@alastairknowles Could you simply place migrations into different locations based on their ‘type’ (data/schema changes)?