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.

[gsmet]

But I wonder if it should be a build time property instead as we don't want to create a Flyway object at all.

[geoand]

We can certainly start out with a build time property and go to runtime if needed instead of going the other way

[gsmet]

I will try to make Flyway more in line with what we decided with active/enabled for Hibernate ORM and friends.

The patch will be a bit complex though and will break things a bit as we need to change the semantic.

Not something I like to do in a micro but I think we will have to live with it.

[nilskuhn]

Although this is merged and assigned to ms 3.4.1, I am still facing this issue at startup, logging "Unsupported Database" using quarkus v3.7.3.

In the documentation, I don't see a config option quarkus.flyway."named-data-sources".enabled. If this is still not implemented, how to configure two datasources of which only one flyway is activated?

[gsmet]

@nilskuhn see quarkus.flyway."named-data-sources".active

enabled has to be set at build time and is global, it disables Flyway entirely.

active can be used per datasource and make Flyway active or not.

[nilskuhn]

Aah, ok, thanks a lot for the fast response, that's great! 😄

I still think, the documentation could be improved:

if activation can be set globally via quarkus.flyway.active, the description is wrong: "... for a specific datasource".

[gsmet]

The first one is for the default datasource. Unfortunately the doc is shared between the two so it's hard to find a wording that works for both.
If you have a proposal, I'm all ears :).

[nilskuhn]

Ok, I see. If the doc is shared between the setting with and without "named-data-sources", I would prefer:

Flag to activate/deactivate Flyway at runtime.