Search code examples
javaspring-bootflyway

How do I make FlyWay run my migrations? "Schema is up to date. No migration necessary."


I have an existing database. I created two migrations

$ ls src/main/resources/db/migration/
V1__create_stats.sql  V2__create_sources.sql

I set the following in application.properties

# Prevent complaints when starting migrations with existing tables.
flyway.baselineOnMigrate = true

Otherwise it would give the error org.flywaydb.core.api.FlywayException: Found non-empty schemagalaxybadgewithout metadata table! Use baseline() or set baselineOnMigrate to true to initialize the metadata table.

When I try to start the app, it skips the migrations and doesn't execute them! I use show tables; in MySQL and see they are not there!

>mvn spring-boot:run
...
2018-05-09 18:43:03.671  INFO 24520 --- [  restartedMain] o.f.core.internal.util.VersionPrinter    : Flyway 3.2.1 by Boxfuse
2018-05-09 18:43:04.420  INFO 24520 --- [  restartedMain] o.f.c.i.dbsupport.DbSupportFactory       : Database: jdbc:mysql://localhost:3306/galaxybadge (MySQL 5.5)
2018-05-09 18:43:04.486  INFO 24520 --- [  restartedMain] o.f.core.internal.command.DbValidate     : Validated 0 migrations (execution time 00:00.030s)
2018-05-09 18:43:04.704  INFO 24520 --- [  restartedMain] o.f.c.i.metadatatable.MetaDataTableImpl  : Creating Metadata table: `galaxybadge`.`schema_version`
2018-05-09 18:43:05.116  INFO 24520 --- [  restartedMain] o.f.core.internal.command.DbBaseline     : Schema baselined with version: 1
2018-05-09 18:43:05.145  INFO 24520 --- [  restartedMain] o.f.core.internal.command.DbMigrate      : Current version of schema `galaxybadge`: 1
2018-05-09 18:43:05.146  INFO 24520 --- [  restartedMain] o.f.core.internal.command.DbMigrate      : Schema `galaxybadge` is up to date. No migration necessary.

I looked at this answer but it didn't help and seemed to give the wrong property name. Here is the schema_version table it created.

> select * from schema_version;
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+
| version_rank | installed_rank | version | description           | type     | script                | checksum | installed_by | installed_on        | execution_time | success |
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+
|            1 |              1 | 1       | << Flyway Baseline >> | BASELINE | << Flyway Baseline >> |     NULL | root         | 2018-05-09 18:43:05 |              0 |       1 |
+--------------+----------------+---------+-----------------------+----------+-----------------------+----------+--------------+---------------------+----------------+---------+

Spring Boot 1.5.6, FlyWay Core 3.2.1

Spring docs - FlyWay docs


Solution

  • OK I found this https://flywaydb.org/documentation/existing

    But didn't follow it. Instead, I moved my migrations from V1__* and V2__* to V2... and V3... and downloaded the production schema into V1__initialize.sql.

    mysqldump -h project.us-east-1.rds.amazonaws.com -u username -p --no-data --skip-add-drop-table --compact --skip-set-charset databasename > V1__initialize.sql
    

    Then when I ran Spring mvn spring-boot:run it ran the migrations.

    (Well actually there was a lot of debugging of the SQL and I had to drop the tables several times and delete rows out of schema_verion and delete old file names from target/.../migration/ but that's another story.)

    I believe it may be possible to set

    flyway.baselineVersion=0
    

    and skip the SQL dump (initialization) based on the info here: https://flywaydb.org/documentation/configfiles. However, having the schema available for future devs seems like the right approach.

    I still don't understand why it didn't run V2__... migration from the original question. If it starts at 1, then migration 2 is still available to run. Had it worked as expected, then I might have understood the problem sooner.