Add support for H2 database

[dstepanov]

Feature description

We support H2 in Micronaut Data, and it would be nice to have it running in the same way, using the test resources.

[melix]

Is H2 widely used beyond testing? The reason I didn't add support for it is that it's usually used for tests.

[dstepanov]

No, it's mostly used for testing

[utsav0209]

@melix @dstepanov are we planning to support the H2 database? If yes, can I open a PR for this?

[melix]

Yes, please, PRs are welcome!

[utsav0209]

@melix looks like Testcontainers does not have any module for the H2 database, what should we do about it?

[melix]

We don't have to use Testcontainers for everything. Actually it would be quite overkill to spawn a container for an H2 database. I would suggest to simply implement a custom resolver.

[utsav0209]

@melix Make sense. Just a couple of questions before I dive deeper...

1. So far we have only added support for modules that use Testcontainers and this is the first time we are adding something like this?
2. I should just make use of TestResourceResolver to implement support for h2
3. Let's say for the initial development we only want to support JDBC and not r2dbc or hibernate-reactive. In that case, where does the module go? Inside test-resource-jdbc or a new module at top level since we are not going to make use of test-resources-testcontainers?
4. Inside the build.gradle files, how is implementation(libs.xyz.xyz) resolved? for e.g. here

[melix]

So far we have only added support for modules that use Testcontainers and this is the first time we are adding something like this?

Actually no, we have other modules, but it is the first one which uses JDBC which doesn't depend on Testcontainers. It was an overlook from my side. So maybe the easiest is actually to leverage the generic test container resolver for this, and use an image like https://hub.docker.com/r/buildo/h2database/#!

I should just make use of TestResourceResolver to implement support for h2

So this is the other option but it would come with drawbacks, like you'd have to reimplement all the logic which we have in the generic jdbc/r2dbc support. Let's see if we can make it work with a container first.

Inside the build.gradle files, how is implementation(libs.xyz.xyz) resolved?

This is version catalogs in Gradle. You can find the library declarations here.

[alvarosanchez]

I personally think that no time should be invested in bringing H2 via Docker. If it is too complex to do that re-implementation, then the best option for users is the existing one via micronaut-sql.

[melix]

Can you clarify what you mean @alvarosanchez ? Bringing H2 via Docker shouldn't be hard, it should only be a matter of specifying the image to use and ports to expose. What do you mean by "existing one via micronaut-sql"?

[alvarosanchez]

Can you clarify what you mean @alvarosanchez ? Bringing H2 via Docker shouldn't be hard, it should only be a matter of specifying the image to use and ports to expose.

I know it would be easy to implement for us, but would make users' experience worse (i.e. slower).

What do you mean by "existing one via micronaut-sql"?

[utsav0209]

@melix @alvarosanchez there is one more thing to consider. The docker images I found on docker hub for H2 are not being maintained it seems, also they are not the official images either. So it might not be in best of our interest to support it via docker environment.

[melix]

So you are suggesting we don't implement this feature, @alvarosanchez ? One thing that test resources provide is the ability to share resources between projects/builds.

[alvarosanchez]

I'm suggesting to not implement it via Docker. Not having an official image is a show-stopper, but even if there would exist one, the user experience would be worse

[melix]

Ok so this is probably blocked on me refactoring the code so that we can have containerless JDBC support.