Allow access to the java.sql.Connection from DbExecute

Environment Details

• Helidon Version: 2.3.0-SNAPSHOT
• Helidon SE
• JDK version: 16
• OS: debian

---

Problem Description

I’m trying to use the CopyManager from the PostgreSQL JDBC Driver to insert some CSV-Data into my database. That requires access to the underlying java.sql.Connection, which seems impossible to obtain from the io.helidon.dbclient.DbExecute / io.helidon.dbclient.DbTransaction passed to DbClient::execute / DbClient::inTransaction. The Connection obtained should be part of the current transaction, if possible. Thank you for the work on Helidon, it’s a joy to use. 😃

Edit: I’m imagining something like this:

dbClient.execute(exec -> {
    Optional<org.postgresql.core.BaseConnection> connection = exec.unwrap(org.postgresql.core.BaseConnection.class);
    // use connection ...
});

Ideally, the JdbcDbClient variant would handle further unwrapping of the connection (I actually need the org.postgresql.core.BaseConnection), but just getting the java.sql.Connection would be fine as well.

[Tomas-Kraus]

Yes, Project Loom will change a lot. With features like fibers, we can probably start simplifying some reactive APIs which won’t be required anymore. But until that, we can’t do much in this area. So you are right, when we are talking about long term plans, there will for sure be some changes to introduce simple blocking API.

[zimmi]

Thanks a lot for the code, I’m sure it will come in handy. Listening to talks about Project Loom I got the impression that it will reduce the need for reactive streams by allowing blocking code to scale in a similar fashion. So I assumed that this is the long term goal of Helidon, especially because it’s an Oracle effort as well. But I’m happy to be told otherwise.

Edit: My needs are fairly minimal as of now. I just need an organized, well documented framework with modern defaults and decent code quality that doesn’t rely on reflection and lots of abstraction layers that make debugging painful. Helidon SE ticks all those boxes. The APIs are very nice and clean, the only thing that makes reading the code harder is the reactive part. I was hoping that this will go away in the future as well.