flyway with one supported and one unsupported Db throws exception at startup

[wernert75]

Describe the bug

There is an application wich uses two databases. One postgresql and one database wich is not supported by flyway.

Until release 3.3.0 this was no problem. Since migration to 3.3.0 there will be an exception at startup: org.flywaydb.core.api.FlywayException: Unsupported Database

For the unsupported db the migration is switched off: quarkus.flyway.olap.migrate-at-start=false

No I tried to disable flyway for the specific db. quarkus.flyway.olap.enabled=false

But it seems, this parameter is only global, for all connections, available.

Expected behavior

possibility to use flyway with mixed datasources wich are supported and not supported by flyway. This was no problem until Quarkus 3.3.0.

Perhaps it is a solution to make the property quarkus.flyway.enabled separate for every datasource

Actual behavior

There is an exception at startup:

2023-08-24 13:38:48,070 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile [devprod, dev]): java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
	at io.quarkus.runner.GeneratedMain.main(Unknown Source)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:104)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: jakarta.enterprise.inject.CreationException: Error creating synthetic bean [0f016e26a2915694b42fad485772394a44058251]: org.flywaydb.core.api.FlywayException: Unsupported Database: ClickHouse 23.7
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.doCreate(Unknown Source)
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.create(Unknown Source)
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.create(Unknown Source)
	at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:113)
	at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:37)
	at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:34)
	at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:32)
	at io.quarkus.arc.impl.ComputingCache.computeIfAbsent(ComputingCache.java:69)
	at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:34)
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.get(Unknown Source)
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.get(Unknown Source)
	at io.quarkus.arc.impl.Instances$3.get(Instances.java:132)
	at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:32)
	at io.quarkus.arc.impl.LazyInstanceHandle.instanceInternal(LazyInstanceHandle.java:32)
	at io.quarkus.arc.impl.AbstractInstanceHandle.get(AbstractInstanceHandle.java:46)
	at io.quarkus.flyway.runtime.FlywayRecorder.doStartActions(FlywayRecorder.java:96)
	at io.quarkus.deployment.steps.FlywayProcessor$startActions2035800939.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.FlywayProcessor$startActions2035800939.deploy(Unknown Source)
	... 13 more
Caused by: org.flywaydb.core.api.FlywayException: Unsupported Database: ClickHouse 23.7
	at org.flywaydb.core.internal.database.DatabaseTypeRegister.getDatabaseTypeForConnection(DatabaseTypeRegister.java:105)
	at org.flywaydb.core.api.configuration.ClassicConfiguration.setDataSource(ClassicConfiguration.java:1091)
	at org.flywaydb.core.api.configuration.FluentConfiguration.dataSource(FluentConfiguration.java:624)
	at io.quarkus.flyway.runtime.FlywayCreator.createFlyway(FlywayCreator.java:71)
	at io.quarkus.flyway.runtime.FlywayContainerProducer.createFlyway(FlywayContainerProducer.java:53)
	at io.quarkus.flyway.runtime.FlywayRecorder$1.apply(FlywayRecorder.java:66)
	at io.quarkus.flyway.runtime.FlywayRecorder$1.apply(FlywayRecorder.java:57)
	at io.quarkus.flyway.runtime.FlywayContainer_0f016e26a2915694b42fad485772394a44058251_Synthetic_Bean.createSynthetic(Unknown Source)
	... 31 more

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cristhiank (flyway), @gastaldi (flyway), @geoand (flyway), @gsmet (flyway)

[geoand]

Can you add a sample that worked for 3.2 but does not for 3.3?

[wernert75]

code-with-quarkus.zip
Here is a simple reproducer. This crashes at startup with 3.3.0. If you switch back to 3.2.4.Final, it will start.
Important: You need a correct db-connection for olap-datasource. If there are for example wrong cridentials, the app will start and no exception is thrown

[geoand]

You need a correct db-connection for olap-datasource. If there are for example wrong cridentials, the app will start and no exception is thrown

How do I start this service?

[wernert75]

You need a correct db-connection for olap-datasource. If there are for example wrong cridentials, the app will start and no exception is thrown

How do I start this service?

you could start a docker container with this command:

docker run -d -e CLICKHOUSE_DB=olap -e CLICKHOUSE_USER=admin -e CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT=1 -e CLICKHOUSE_PASSWORD=admin -p 8124:8123/tcp clickhouse/clickhouse-server

[geoand]

Thanks, I tried this and I can reproduce the problem.

The reason this now happens is due to changes in Flyway.

So I think we have to have an enabled property in FlywayDataSourceRuntimeConfig as well. WDYT @gsmet ?

[gastaldi]

That makes sense, but I guess the question is why Flyway is being executed in all datasources by default?

[geoand]

Why wouldn't it in the absense of a way to control it?

[gsmet]

Yeah I agree we need an enabled bit.