This module provides a very thin layer to use Spring Boot’s integration with Flyway


Add the following dependency:


Also add the following module to your AppManifest:

public static class AppManifest {

Configure Flyway connection parameters:
spring.flyway.default-schema=SIMPLE             (1)
spring.flyway.schemas=SIMPLE                    (2)
spring.flyway.create-schemas=true               (3)    (4)
1 the default schema managed by Flyway (containing the schema_version table); see flyway.defaultSchema config property (Flyway docs) for more info
2 all of the schemas managed by Flyway; see flyway.schemas config property (Flyway docs) for more info
3 whether Flyway should automatically create schemas ; see flyway.createSchemas for more info
4 instruct Apache Isis to not attempt to create schemas

The ORM should also be configured to not automatically create tables:

  • if using JPA/Eclipselink, then:
  • if using JDO/DataNucleus, then:

Managing different variants

When running with an in-memory object store - either for prototyping or integration tests - you will need the database tables to be created first.

In normal circumstances this is most easily accomplished with the ORM automatically creating the tables (and Flyway disabled).

However, if you want your tests to check your Flyway scripts beforehand, there is nothing to prevent you from using Flyway all the time, even for integration tests. One point to be aware of though is that the DDL syntax may vary between an in-memory database (such as H2) and a typical production database (such as PostgreSQL or SQL Server).

Luckily, Spring Boot’s Flyway integration allows different variants of scripts for different vendors to be stored, in db.migration.{vendor} package (where {vendor} is as defined by the DatabaseDriver class). The simpleapp starter app also provides an example of this.