Explore topic-wise InterviewSolutions in .

There are many benefits of JDBI Library.

Some of them are :

1. It’s lighter than an ORM (LIKE Hibernate or Spring)
2. JDBI is a performant, PRODUCTION ready, easy to use library that takes the pain out of JDBC
3. From a MAINTENANCE perspective I find it incredibly easy. SINCE it’s annotation and interface based it’s easy to mock out for testing. And making CHANGES to either the queries or interface is simple and straightforward, there’s no need to rewrite a bunch of code.

There are many benefits of JDBI Library.

Some of them are :

• Hibernate can generate large numbers of unnecessary queries, even due to minor misconfigurations. When PROPERLY configured it still often performs worse than simple SQL queries.
• Hibernate is definitely more of an abstraction, and in my opinion is great for a simple apps. But my in experience, as things get more complicated the abstraction leaks. You end up having to put debug statements to see the queries produced by hibernate, tweaking the annotation to get different queries, hopefully with a more performant query plan.
• Hibernate is opinionated about your data structure. When you have a data structure that doesn’t folow it’s notion of keys and relationships the Object-relational IMPEDANCE Mismatch is GOING to hit you even harder. Hybrid-ORM frameworks, such as JDBI, allow more flexibility when mapping to objects and thus provide more runway before you have to start coding significant work arounds for this issue.
• You don’t see the performance problems until you scale! When your application is small and simple EVERYTHING seems to go along SMOOTHLY, then you scale and all of a sudden hibernate queries are the root of your performance problems.

JDBI usually requires three steps to get to a result:

1. Obtain a connection
2. Prepare a STATEMENT
3. FETCH results (MEANING ITERATE over a result set, even if you only need one value)

JDBI usually requires three steps to get to a result:

There are couple of reasons why should you prefer it over HIBERNATE:

1. You don’t NEED to worry about lazy/eager fetching and how that is going to affect your query time on large data sets.
2. You know exactly what SQL is going to be executed to acquire the data you are requesting. With Hibernate, you can sometimes have to do a lot of messing around with HQL and configuring your objects to what you intended to have returned. You ultimately resort to SQL, but then have the DIFFICULTLY of properly mapping your results back to your domain objects, or you give up and allow hibernate to fetch them one by one.
3. Mappings aren’t complicated because you manage them on your own and you don’t have to rely on getting the right combinations of annotations and optimizations.

There are couple of reasons why should you prefer it over Hibernate:

The SQL Object extension sits atop Core, and provides a declarative interface. Tell Jdbi what SQL to execute and the shape of the results you LIKE by declaring an annotated Java interface, and it will provide the IMPLEMENTATION.

// Define your own declarative interface

public interface UserDao {

@SqlUpdate("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)")

void createTable();

@SqlUpdate("INSERT INTO user(id, name) VALUES (?, ?)")

void insertPositional(INT id, String name);

} 

The SQL Object extension sits atop Core, and provides a declarative interface. Tell Jdbi what SQL to execute and the shape of the results you like by declaring an annotated Java interface, and it will provide the implementation.

// Define your own declarative interface

public interface UserDao {

@SqlUpdate("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)")

void createTable();

@SqlUpdate("INSERT INTO user(id, name) VALUES (?, ?)")

void insertPositional(int id, String name);

} 

• JDBI is a convenience library built on TOP of JDBC. If your database has a JDBC driver, you can use Jdbi with it.
• JDBC works very WELL but generally SEEMS to optimize for the database VENDORS (driver writers) over the USERS. jDBI attempts to expose the same functionality, but in an API optimized for users

• Hibernate and JDBI START with very different assumptions about the relationship between the DEVELOPER and the database.
• Hibernate supposes that the developer is agnostic to the choice of database and would really rather not be BOTHERED with writing SQL.
• JDBI PRESUMES that the developer is deeply connected to the database and its design and implementation choices, and would prefer a straightforward mapping from HANDWRITTEN SQL to Java.

• JDBC is a long-established standard used in Java to access SQL databases. DB Vendors implement a JDBC driver so that all DBS can be accessed in a uniform manner. Practically EVERYTHING done with databases in Java USES JDBC.
• JDBI is a convenience library built on top of JDBC. If your database has a JDBC driver, you can use Jdbi with it. JDBI is a performant, production ready, EASY to use library that takes the pain out of JDBC.

JDBI EXPOSES relational DATABASE access in TWO different STYLE APIs

• Fluent style API
• SQL Object style API

JDBI exposes relational database access in two different style APIs

The CORE API provides a FLUENT, imperative interface. Use Builder style objects to wire up your SQL to RICH Java data types.

List<Users> users = handle.createQuery("select * from users where name = :name and id = :id")

.bind(0, "TOM")

.bind("id", 1)

.map(Users.class)

.list();

The Core API provides a fluent, imperative interface. Use Builder style objects to wire up your SQL to rich Java data types.

List<Users> users = handle.createQuery("select * from users where name = :name and id = :id")

.bind(0, "Tom")

.bind("id", 1)

.map(Users.class)

.list();

• JDBI stands for Java DATABASE Interface. 
• JDBI is a performant, production ready, EASY to use library that takes the PAIN out of JDBC.