Does it make sense to use trino-client instead of trino-jdbc?

[gaeljw]

Hello folks,

We started using Trino JDBC driver to query Trino from a JVM application.
However I feel like there's no benefit in using the JDBC layer if under the hood it is "just" HTTP calls to Trino server. On the contrary it can lead to some overhead in terms of performance.

Am I missing something? Is there any benefit in using the JDBC layer?

I'll try but if anyone can confirm I'm not going in a wrong direction, I was thinking to implement something like this:

var client = ... // Create a StatementClientV1 with SQL query

do {
  var rows = client.currentRows()
  // Process rows somehow
} while (client.advance())

client.close()

Last question: am I right that there's no async API exposed in trino-client?

Thanks for any comment :)

[hashhar]

there's no async API since the protocol itself is completely serial (you cannot get next page unless you parse current response).

JDBC driver does provide some "async" over the HTTP Client by buffering results - that itself is one good reason to use the JDBC driver instead of client directly.

JDBC also has well-defined semantics (and APIs) for interacting with the data - the client's serialisation format is not a stable API.

[gaeljw]

Thanks for your answer @hashhar

JDBC also has well-defined semantics (and APIs) for interacting with the data - the client's serialisation format is not a stable

I agree that JDBC exposes a well defined API, that can be a pro for JDBC indeed.

However I was under the impression that trino-client takes care of the deserialization. I would definitely not deserialize myself using my own client.

there's no async API since the protocol itself is completely serial (you cannot get next page unless you parse current response).

I should've probably explained myself better, I was rather looking at a non blocking API that would give something like a RxJava Stream. But that's not an issue. One can wrap the existing API in its preferred Async/Reactive API.