Reactive H2 driver for Quarkus

[aaron-axisa]

Description

When using a reactive implementation for databases, during tests it is sometimes desired to swap to an h2 database to avoid needing to have a fully fledged database available.

Currently there seems to be no driver integration for reactive h2 available which makes this solution impossible.

R2DBC h2 integrations seem to already exist to some extent https://github.com/r2dbc/r2dbc-h2

Source discussion: https://stackoverflow.com/questions/69363380/quarkus-reactive-named-data-source-em-is-null?noredirect=1

Implementation ideas

No response

[geoand]

cc @tsegismont

[famod]

FWIW, Quarkus is still on h2 1.4.197 but r2dbc-h2 seems to be on h2 1.4.200.
See also: #9354

[tsegismont]

Vert.x does not provide a reactive H2 driver yet, it's been asked a couple times but not a priority for the community. PR are welcome and we can assist anyone volunteering to implement it.

@famod I would recommend to stick to the database you use in production. Run it inside a container during the development/test phase. Quarkus can even do that automatically for you with Dev Services.

[famod]

@famod I would recommend to stick to the database you use in production. Run it inside a container during the development/test phase. Quarkus can even do that automatically for you with Dev Services.

Sure, this is the safest but usually also the slowest approach (especially if a db container has to be started for each test run). That's why we usually have h2 for QuarkusTests. YMMV!

[cescoffier]

Something doable would be to use the Vert.x JDBC Client (implementing the same SQL Client interface). As H2 should only be used for tests that could be acceptable.

[Sanne]

I don't think we should work on this, unless it's really trivial to put such an adapter in place.

It's extremely easy to use any other RDBMs with Quarkus nowadays, so there is no compelling reason to use in-memory testing helpers anymore.

[famod]

so there is no compelling reason to use in-memory testing helpers anymore.

I cannot comment on the effort/benefit ratio of creating such a driver, but in general h2 is still usually much faster than any automatic containerized db approach.

[maxandersen]

I agree we should just consider this if we can make it fairly easily, but..

is no compelling reason to use in-memory testing helpers anymore.

is not necessarily true. h2 is faster than devsservice and it runs everywhere where as devservice requires docker/containers which is not available everywhere no matter how much we wish that would be true .

[Sanne]

But H2 is not the same DB that people then run in production, so while it's true that it might be slightly faster to start it's still not a valid replacement, it's still only a good choice for limited phases of development only, and still needs "the real thing" to run at various other phases in the development cycle. So you can't avoid running the non-H2 flavour.

This is a tradeoff that was heavily in favour of H2 when getting a RDBMS was very inconvenient, but the balance is getting tipped.

I agree we should just consider ...

Sure it would be nice - but in terms of the strict prioritization I have to do, my team won't work on this. Patches welcome.

[aaron-axisa]

I agree that in an ideal world that we would use the same database to test against however in older ocmpanies even getting docker installed on some servers is a whole beurocratic process that often ends in failure. As such H2 is the only otpion for tests sometimes.
At this point the only options available are either have to setup a full database for tests to run against, swap over to a non-reactive databse layer or just go back to spring.

[gsmet]

I'm going to close this as won't fix on our side as I see no point tracking something noone really plans on working.

If one day Vert.x has a H2 driver, I'm pretty sure @tsegismont will create the Quarkus extension as he did for the other drivers.

[apatrida]

whats wrong with support Vert.x JDBC wrapper? Seems like a win to bring in HSQLDB / H2 / Derby in one shot.

https://vertx.io/docs/vertx-jdbc-client/java/

And about the "same database you use in production" ... some of these ARE used in production scenarios. Demos, local runs, small devices, and you don't really know to make that judgement about what people need to use from the most common databases used in JVM development.

@Sanne / @cescoffier / @tsegismont

[maxandersen]

I don't think there is an issue in doing that just that it's not going to be reactive - only pretend to be; meaning you will get different execution behaviour ... If aware of that it should just work I reckon ?

[apatrida]

It is what it is, and there isn't another option other than R2DBC and changing to a different API. I don't think this breaks the Reactive semantics. It maybe carries some risk in the LOOM world where JDBC isn't yet LOOM friendly and can cause a virtual thread to bind to the real thread.

[benstonezhang]

I made a draft routines for reactive h2 client, would you like to have a look ?
https://github.com/benstonezhang/quarkus/tree/reactive-h2-client

[cescoffier]

The problem with the reactive API using a JDBC driver is the heavy usage of worker threads. Everything goes to a worker thread making such kind of solution expensive and slow. It also limits the concurrency and may use the worker threads for a long time (which means that the rest of the system may have to wait to be executed).

Once you accept these limitations, sure, you can use that approach. But don't expect any benefits.

[benstonezhang]

While we run test, the performance should not be an issue. We use mariadb in produce environment, but a reactive h2 client make jenkins build the artifact easy.
BTW, we always try to use NamedQuery to let quarkus compile these HSQL and found any potential issue. Of course, we extends the hibernate mariadb Dialect class to workaround some function not supported by mariadb.