Hibernate vs JDBI

[Tom McKenzie]

Hello Dropwizard Folks

We are currently using Hibernate with Dropwizard 0.6.1 and we are finding it to be complicated to work with because of problems managing lazy loading.  Usually we want to just pull the rows for a single table not all the other tables it's joined to.  Any recommendations on best practices for Hibernate and REST?  It seems the OpenSessionInView is contreversial see http://blog.frankel.ch/the-opensessioninview-antipattern.

I'm also wondering if anyone has experience working with JDBI and the pros and cons vs Hibernate.  It seems like Hibernate has a lot features we aren't using and is complicated.

Thanks in advance!

P.S. If folks have other frameworks like for data access I'm interested in those too.

[Christopher Currie]

import std.disclaimer; // Opinions are my own, and not the library devs.

From my perspective, 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. Which you choose depends largely on which perspective you find appropriate for your project.

From your  description, it sounds like JDBI *might* be a good fit, if you're willing to get your hands dirty writing the SQL queries. But unless your DAO interfaces are *really* clean of Hibernate dependencies, it's a non-trivial amount of work to convert for a project of meaningful size, so unless your operational pain is high, the conversion might not (yet) be worth it.

My personal experience is that JDBI is a terrific library that is simple and clean to work with and has minimal baggage. YMMV.

HTH,

Christopher

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mutebl...@gmail.com]

I am just about to beging to build my own product and I am wondering about the architecture of my application. Currently I am wondering about pros and cons of using hibernate over JDBI and I am not still sure which one to use. I have been using previously hibernate and other orms and also I have been working with spring templates and other low level libraries. 
Usually the first problems with hibernate comes from the lazy/eager loading stuff. But I think that you could change those on runtime using criteriabuilder api?

eg.

List<User> cats = session.createCriteria(User.class)
    .add( Restrictions.like("name", "Jimmy%") )
    .setFetchMode("colleagues", FetchMode.EAGER)
    .setFetchMode("friends", FetchMode.EAGER)
    .list();

{{mbd

[mutebl...@gmail.com]

Sorry for another reply, but basically I am also pondering about these same problems.

I am trying to avoid Anemic Domain Mode with out using Data Transfer Objects and I would like to keep my Entitys/Models very simple with minimal amount of annotations..
When you are mixing this with "try to avoid procedural programming" well I am going nuts.. :)

On Sunday, April 6, 2014 1:40:22 AM UTC+3, Tom McKenzie wrote:

[CAB]

I have used both. I agree with the points Christopher makes, and I have faced some of the issues described in that article. 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. Based on my experiences, for new apps I would just choose jdbi. I like having the control out of the box, even at the cost of more sql writing. 

Just like Christopher, that's only my opinion.

[Shan Syed]

I elected to go with JDBI, but one thing I couldn't figure out is annotation-driven transactions.. would make things a little easier for spanning a transaction across methods.

DW has "UnitOfWork" which I *think* is similar to Spring's Transactional

I wish there was something like that for JDBI - unless there is, and I just can't find it?

[Christopher Currie]

I'm not sure what you mean by "annotation driven transactions." The simplest mechanism in JDBI for executing multiple methods on a DAO in a transaction is to mix-in the "Transactional" interface, and use the "inTransaction" method. Documentation is here:

http://skife.org/jdbi/java/library/sql/2011/03/16/jdbi-sql-objects.html

If that doesn't meet your needs, you might ask on the jdbi mailing list (jd...@googlegroups.com) or IRC channel (#jdbi on irc.freenode.net).

[Shan Syed]

I meant something comparable to this: 

"Dropwizard uses a declarative method of scoping transactional boundaries. Not all resource methods actually require database access, so the @UnitOfWorkannotation is provided"

http://dropwizard.readthedocs.org/en/latest/manual/hibernate.html

for JDBI

I guess I could write an annotation myself that via AOP opens a transactions at the beginning of a method, closes/commits it at the end, and rolls it back upon error, but it's not a small task

[Christopher Currie]

That's effectively what JDBIs Transactional.inTransaction does, just in code rather than with annotation. If you need to have a transaction operate across DAOs, that's possible but not typical usage.

I see the appeal of an annotation; JDBI's DAOs don't use a global session, though, so if you want to do it, you'd have to inject the DAO into the methods as parameters, or at the very least a Handle object with the transaction opened.

That said, if there's a lot of demand for this paradigm, it could be worth a feature request for dropwizard-jdbi.

[Tatu Saloranta]

On Mon, Apr 7, 2014 at 12:28 PM, Christopher Currie <chris...@currie.com> wrote:

That's effectively what JDBIs Transactional.inTransaction does, just in code rather than with annotation. If you need to have a transaction operate across DAOs, that's possible but not typical usage.

I see the appeal of an annotation; JDBI's DAOs don't use a global session, though, so if you want to do it, you'd have to inject the DAO into the methods as parameters, or at the very least a Handle object with the transaction opened.

That said, if there's a lot of demand for this paradigm, it could be worth a feature request for dropwizard-jdbi.

I think this is the key, since core jDBI has no knowledge of container, and simply has no access to add scoping. But a simple dw extension could plug in to hook the life-cycle of transaction with endpoints/resources.

This is actually a common challenge with libraries vs platforms/frameworks: latter often assume more control over code flows, which helps in supporting end-to-end handling, but also makes it more difficult to reuse pieces (since it leads to 'too many chefs in the kitchen' problems wrt who's the boss).

-+ Tatu +-

[Justin Rudd]

Typing on my phone, so I'll keep this short. You need to be careful with inTransaction using proxies created by onDemand. It does not behave like Spring's PlatformTransactionManager. You need to use the Handle that gets passed in to create your proxies.

This is probably common knowledge, but I figured I'd mention it. I know it bit us when we first started using jDBI.

[Shan Syed]

in the end, I think I could achieve what I want if I passed around some kind of session-aware object to well designed classes, that did these commits and rollbacks in a more declarative way

the desire for an annotation is just to cater to my laziness ;P

[Christopher Currie]

A caveat: JDBI's transactional model encourages (I think by design) keeping transactions as short as possible, because long-lived transactions are a performance bottleneck at scale.

If your request handler needs to perform a lot of database interaction, such that you feel you need to be passing around a session object, consider instead passing an object that collects a set of proposed changes, and applying the changes all at once at the end of your request.

[Tom McKenzie]

Thanks for everyone's input.  Very helpful!