discussion: introduce flyway for db initialization about camunda-bpm-spring-boot-starter

[stphngrtz]

Just in case anyone is facing the same problem, this is how I was able to run Flyway migration just before the bpm engine gets created (and thus complains about missing tables):

@Bean
AbstractProcessEnginePlugin flywayInitializingProcessEnginePlugin(FlywayMigrationInitializer initializer) {
    return new AbstractProcessEnginePlugin() {
        @Override
        public void postInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
        }
    };
}

By requesting a bean of type FlywayMigrationInitializer the auto configuration of Flyway (which includes running the migration) kicks in during initialization of the bpm engine.

[osteinhauer]

Hi Jan.

I have used flyway many times even in conjunction with camunda. I like flyway ;)

The main issue is managing the script/schema versions. Someone needs to provide the scripts in the flyway way. One way could be to copy the scripts and introduce flyway properties to give control at startup.

Haven't checked but using liquibase (which is supported by spring boot too) could be easier because migration definitions are separated from scripts . Maybe it is a good idea to support both.

[osteinhauer]

Do you like to integrate your PoC so it can be activated if flyway is in the classpath?

[jangalinski]

closed, good idea but no reason to keep it open

[stphngrtz]

Why not? I'd love this feature.

Just putting flyway to the classpath and disabling the schema update of camunda bpm seems not to work because the schema validation of camunda bpm runs before any flyway script has been executed :-/