8

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

Chloe
  • 25,162
  • 40
  • 190
  • 357
  • How are you calling flyway in your `Application` root class? – Luay Abdulraheem May 09 '18 at 23:53
  • I don't have to call FlyWay from my application. Spring does it automatically. https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html#howto-execute-flyway-database-migrations-on-startup – Chloe May 10 '18 at 00:05
  • Have you tried putting your migration scripts under: `db/migration/mysql` ? – Luay Abdulraheem May 10 '18 at 01:25

2 Answers2

2

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.

Chloe
  • 25,162
  • 40
  • 190
  • 357
2

With a Spring boot application that already have an existing database, configure this in your application.yml:

flyway:
    baseline-on-migrate: true
    baseline-version: 0

And start your migration scripts at 1, like this : V1__script_description.sql, V2__script_description.sql, ...

Victor Petit
  • 2,632
  • 19
  • 19