Running dynamically generated flyway scripts in java

Question

I want to run some flyway scripts to set up my database for integration tests.

I have a flyway script V1-XXX at src/test/resources/db/migration and I am copying another file V2-XXXX at the same location after loading application context. Then I am using the following code to migrate the 2 scripts. Only the first script is getting migrated. Can someone please let me know how can I successfully migrate both the scripts?

Flyway flyway = Flyway.configure()
                          .dataSource("jdbcUrl",
                                      "username",
                                      "password").load();
flyway.migrate();

The flyway version I am using:

compile "org.flywaydb:flyway-core:5.2.4"

I added the following code to get pending migrations info:

    flyway.setLocations("filesystem:src/test/resources/db/migration");
    MigrationInfoService migrationInfoService = flyway.info();
    MigrationInfo[] migrationInfos = migrationInfoService.pending();
    flyway.migrate();

and I see the following logs:

2019-07-22 16:07:27.046  INFO 46406 --- [           main] o.f.core.internal.command.DbValidate     : Successfully validated 2 migrations (execution time 00:00.022s)
2019-07-22 16:07:27.057  INFO 46406 --- [           main] o.f.c.i.s.JdbcTableSchemaHistory         : Creating Schema History table: "public"."flyway_schema_history"
2019-07-22 16:07:27.074  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Current version of schema "public": << Empty Schema >>
2019-07-22 16:07:27.075  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Migrating schema "public" to version 1.1 - create-pgcrypto
2019-07-22 16:07:27.089  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Migrating schema "public" to version 20190712113815 - creating-initial-tables
2019-07-22 16:07:27.138  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Successfully applied 2 migrations to schema "public" (execution time 00:00.082s)
2019-07-22 16:07:28.603  INFO 46406 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.

2019-07-22 16:07:28.625  INFO 46406 --- [           main] o.f.core.internal.command.DbValidate     : Successfully validated 1 migration (execution time 00:00.003s)
2019-07-22 16:07:28.632  INFO 46406 --- [           main] o.f.c.i.s.JdbcTableSchemaHistory         : Creating Schema History table: "public"."flyway_schema_history"
2019-07-22 16:07:28.643  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Current version of schema "public": << Empty Schema >>
2019-07-22 16:07:28.643  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Migrating schema "public" to version 1.1 - create-pgcrypto
2019-07-22 16:07:28.656  INFO 46406 --- [           main] o.f.core.internal.command.DbMigrate      : Successfully applied 1 migration to schema "public" (execution time 00:00.024s)

It seems flyway is detecting 2 scripts but migrating only 1 script.

Answer 1

您可以在此处使用 Flyway 的设置位置方法：

flyway.setLocations("filesystem:src/test/resources/db/migration");

Answer 2

So I had the same result.

My approach was slightly different. I am creating a new DB (via docker) and I am creating a new database schema (programmatically, not using flyway).

Once the DB was created I ran flyway.baseline() (as advised by flyway's console). It turns out this was not necessary and left an entry in table flyway_schema_history . The console output also informed me the current version was 1 , which didn't seem unreasonable... but it seems it was the cause of the failure to execute migration script V1 .

The following log output below demonstrates this quite nicely and perhaps you'll see similar in your own logs.

flyway.baseline()

22:00:44.288 [main] INFO org.flywaydb.core.internal.command.DbBaseline - Successfully baselined schema with version: 1

flyway.clean()

22:04:52.821 [main] INFO org.flywaydb.core.internal.command.DbMigrate - Current version of schema `test_db`: << Empty Schema >>

This single entry in the table (when no clean() is applied) has a version 1 in the version column.

I tore down the DB and re-spun it up from scratch, this time I swapped my V1 and V2 files around. This time the results were reversed. I then renamed my V1 file to V3 and both V2 and the now V3 files were applied as expected.

Ultimately, check the flyway_schema_history version column does not already have your version number in use before executing your migration.