Arie
Arie

Reputation: 12425

Native SQL approach for Quarkus applications

Coming from Dropwizard, I’d like to give Quarkus a try.

My question is how to set up a SQL central approach, like JDBI, that benefits from the features Quarkus offers: reactive, connection pool management, transactions.

I was very happy with JDBI as database library, that comes standard with Dropwizard:

This example shows its approach, in case you are not familiar (very low code, SQL in annotations):

public interface UserDao {
    @SqlQuery("SELECT * FROM users WHERE id = :id")
    @UseRowMapper(UserMapper.class)
    User getUser(@Bind("id") int id);
}

I like using fancier postgres features, and think using SQL for that hits the nail. I’m not interested in Hibernate’s or Panaches entity mapping and query languages, but if I need to use it to take care of mapping objects, so be it.

The reactive Postgres driver lets you write custom SQL, but doesn’t seem to provide tools to manage prepared statements and mappings as easy as JDBI (I foresee lots of boilerplate code).

There is this attempt to integrate JDBI for Quarkus, but seems early stage/low adoption/little documentation.

Any tips from people using a similar workflow? Or tutorials that I missed?

Upvotes: 0

Views: 1015

Answers (1)

fwelland
fwelland

Reputation: 545

Having pretty good luck with using JDBI from Quarkus 2.16.x. Not using the JBDI extension -- didn't know about it when first started on this JDBI/Quarkus project -- but looking back, not seeing the value of it...but could be missing something.

More or less, we got a producer making Jdbi handle and then we just use JDBI as 'normal'.

Works pretty well; we use it for simple insert/updates to some tracking records, and then to read/select with larger OLAP like queries. In both cases, using the interface approach, a bit like your comments above, but use the exteranl SQL files (via UseClasspathSqlLocator).

HTH!

Upvotes: 0

Related Questions