Drawbacks to Hibernate

  Subscribe
8/24/2006 - Marco (updated on 11/13/2017)

The comment, Re: iBATIS vs Hibernate, offers some good advice for when to use iBATIS and when to use Hibernate. The damning sentence for Hibernate follows:

If you try to shoehorn hibernate into a relational model created by a DBA who could care less about objects and thinks in terms of tables, columns, relationships and record sets, then you will get along better with your DBA if you use iBATIS, especially if the model is complex and may entail queries with outer joins and nested subqueries.

Since when did outer joins or sub-queries become "complex"? These are exactly the drawbacks we've discovered in Hibernate, as well. You have to do handstands to get it to do an outer join; once you've got one, the object-structure returned by Hibernate is different than it was before and your processing code is useless. Which takes us to this next sentence:

iBATIS is more flexible, has a shorter learning curve, but can take more time to develop and maintain, since you have to write all your queries and if your object model changes you have to go through all your queries and make sure to make all the necessary changes to reflect the changes in your object model.

With Hibernate, you have to re-adjust how you process the query result if you change something that Hibernate considers significant (like restricting an inner join -- a big no no). Each solution has the downside of requiring maintenance when something changes. iBATIS fails outright when it tries mapping (database) fields to (object) properties that no longer exist. With Hibernate, it's possible that the code keeps running fine -- it just starts reporting 20 objects, where before there were 5 (with 15 children distributed among them).

The article, iBATIS 2.0 Released, provides more information in the comments.

anon@np45.iauq.com
11/13/2017

Queryinterfaceinhibernate3

In Hibernate3.jar Query interface is having executeUpate() but in JavaDocs it is executeUdpate(). while working with hibernate3.0 please make sure that java developer should use correct name of the method to avoid problems. we need wait for correct release for hibernate

Jitender Kumar Mourya Senior Developer IBM

jitender
11/13/2017

Queryinterfaceinhibernate3

In Hibernate3.jar Query interface is having executeUpate() but in JavaDocs it is executeUdpate(). while working with hibernate3.0 please make sure that java developer should use correct name of the method to avoid problems. we need wait for correct release for hibernate

Jitender Kumar Mourya Senior Developer IBM

anon@adsl-62-167-30-246.adslplus.ch
11/13/2017

If you want to control join strategies, Hibernate is probably the wrong tool

After all these years of gathering experience with ORM, it has become clear that Hibernate is not a good choice if you want to stay in control of the SQL it renders (unless you resort to plain SQL, of course). A good article explaining where Hibernate fits best is this one here: http://mikehadlow.blogspot.ca/2012/06/when-should-i-use-orm.html

While iBATIS (now MyBatis) solves the impedance mismatch by not creating any SQL abstraction, it doesn't offer other goodies that Hibernate has, e.g. criteria query (typesafe querying), automatic mapping, automatic CRUD, etc.

jOOQ (http://www.jooq.org) is the library that covers these requirements best. It introduces SQL as an internal domain-specific language to Java, providing typesafe access to the SQL language and to result records. It lets you fully control the SQL it renders, while allowing you to provide custom record to POJO mappings strategies.

Sign up for our Newsletter