Hibernate, just stop it!

In 2001 Hibernate was created to ease development for the hordes of unhappy developers fighting with Java’s poor EJB implementation. EJB was so confusing and over-engineered that Hibernate’s simpler approach seemed like pure heaven in contrast.

Eventually hibernate inspired Java’s JPA and became a certified implementation of JPA.

History lesson is over.

Lets look at the status today. Right now Hibernate is a very popular ORM java library, maybe the most popular of them all. And I can’t understand what is wrong with people.

Hibernate promises to simplify database access, it maps your objects to a database schema and is database agnostic.You connect to any relational database you want, annotate your classes and variables, and Hibernate does all the magic. No SQL! Magic! Magic I tell you!!

I have tried using Hibernate for several projects. Every time, using Hibernate has been ok until at some point I start using many-to-many relationships, or want control over the order of things to be loaded. I start fiddling with the annotations, lazy loading, try HQL, and start getting pissed off. Then I look at what sql queries are being sent to the database, and it hits me every time:

As soon as a project gets to a certain size Hibernate’s magic ends up getting in the way.

I most often know how I want the database to be, and I know SQL enough to get the results I want. If I want to tune queries or write queries, then SQL is the bloody language for it. Not HQL or any other ORM bastardized substitute. What is wrong with using the query language created for this purpose?

Hibernate is useful for newbie developers that are scared of SQL and just want it to go away, while they riddle their class files with annotations, and let Hibernate automatically generate a database and puke endless sql queries over it.

Those developers should grow up and start asking themselves why they are using a library that mangles their understanding of how databases work, messes up the classes with annotations, and has a tendency to need tuning to get the number of queries and performance to an acceptable level once your project goes beyond crazy simple.

Am I missing something here, or is it stupid to have to tune the library that is supposed to simplify your database access, so that it isn’t interfering with your programs access to the underlying database?

I agree that using JDBC directly is a hassle. Having to do all the setup, handle connections, make sure you call rollback when an exception occurs in a transaction, do your own caching and so on… it can get tedious.

A friend and colleague of mine (Lars Aaberg) has the same opinion as me, and actually did something about it. Instead of using a monster ORM solution, he made his own library, called Sql2o  that helps with connection handling, transaction handling and batching, and then gets right out of the way.

Sql2o supports method chaining which can be nice for readability, and can automatically map tables to classes (using reflection) for simplicity. Sql2o is not an ORM, and it does not do any table or query generation for you. You have to make your database, and you have to write the sql queries to manipulate the data, but Sql2o helps with the rest and removes most of the JDBC boilerplate code that you normally end up having to write.

So now I get the best of both worlds. I have full control of the database and queries, and don’t have to write tons of boilerplate code to get things done. Combine that with using Play Framework and its built in caching, asynchronus job execution, and suddenly web application development with Java is pure joy.

Now go and remove Hibernate from your project, and start getting control over your database and queries! It will save you a lot of annotation fiddling and you will thank yourself a few years down the road when you have a better understanding of databases, and see some other developer swearing at his Hibernate-dependent project.

 

PS! If you are still not convinced, then have a look at this great video from Christin Gorman’s lightening talk titled “Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity”.

 


18 Responses to “Hibernate, just stop it!”

  • Alfredo Zuloaga Says:

    I thought you don’t use all the power of hibernate like cache or JPA, if you don’t like Hibernate you give a try to Ibatis or Spring SQL as good alternatives to hibernate they give you all power of SQL that you project needs.

  • Richard Vowles Says:

    or even ebean which gives you both sql and orm and has been around for years.

  • Ricki Sickenger Says:

    Thanks for the comment!

    ebean looks like a nice alternative, although I am not really that interested in the ORM capabilities. I just want something that simplifies the handling of connections, transactions and batching, so I get to use sql, without the boilerplate code that jdbc requires. :-)

  • Ricki Sickenger Says:

    Alfredo: Thanks for the comment!

    My problem with Hibernate is the way it fools people into thinking that complex database issues are object-relational problems. Hibernate, JPA and a lot of other ORM’s keep you thinking about the objects and not the database, but that abstraction falls apart as soon as you have to tweak for performance issues. :)

  • Michael Krog Says:

    If pure SQL queries are wanted, then Spring JdbcTemplate is really nice:
    http://static.springsource.org/spring/docs/3.0.x/reference/jdbc.html

  • Paul Zepernick Says:

    Why not just use the Hibernate SQLQuery class when you want to execute raw SQL, and you can even have hibernate bind it back to your model? That is what I have done in the past instead of trying to create a complicated query with HQL.

    Hibernate really excels at doing CRUD work. I agree anything complex should just be handled through straight SQL.

  • Ricki Sickenger Says:

    Hi, thanks for the comment.

    Regarding just using SQLQuery class and using the Hibernate binding, I feel that any project other than a simple throwaway thing usually ends up with one-to-many or many-to-many relations and propagating changes. This is when conforming to Hibernates way of thinking gets just as difficult or worse than just working with the database directly.

    That is my humble opinion ;-)

  • Richard Vowles Says:

    My comment with using Ebean (which is default on Play2 Java) is that it treats SQL as a first class citizen, allowing you to swap back and forth between the two easily.

    Its documentation specifically says “SQL is much better for a whole lot of stuff, you should just use it”. It lets you use it directly, load partial data back into an entity model and then spelunk from there, it has a fluid API and does instrumentation to keep fast. It also does auto-tuning of your queries if you aren’t use SQL which is crazy cool.

  • Ashwini Says:

    I am glad someone wrote this! Thanks :)

  • Devanshu Says:

    Absolutely True!!! I agree 1000% with you. I mean look at the code annotations annotations annotations…everywhere. It looks so nasty and complicated with all those hibernate code…

    There is so much automation in Java code generation for hibernate that virtually everything is being generated through tools…. Although there already exists but why can’t these open source guys focus on designing an extensive gui based query builders to generate the most complicated queries.

    Hibernate is over hyped.

  • Rakesh Waghela Says:

    Nice catch on hibernate, one open source project which has impressed a lot of guys in java community is http://www.jooq.org

    Type Safe SQL In Java ! Give it a try as an Hibernate Alternative !

  • Kapil Says:

    This is how I typically break it down.

    Use ORM to map my object to DB model. Use the ORM for the basics
    – Create
    – Update
    – Delete
    – Simple Read by PK or UK.

    For all other finders I use my own SQL. My last implementation I used JPA with Eclipse Link and have been happy with it.

    I am about to start playing with EBean soon. Curious to see the experience others have had with EBean.

  • Lukas Eder Says:

    You might enjoy visiting http://www.no-more-hibernate.com

    Although Hibernate (and ORMs in general) surely have their place, as sometimes, “magic” is good enough, SQL should really be put back into Java as a first-class citizen.

  • Mladen Adamovic Says:

    I’ve seen many projects which have bad performance and did use Hibernate or JDO. I hate those technologies (along with JPA).

    After writing thousands of line of JDBC code I’ve realized how it could be done properly.

    After analyzing dozens of hibernate alternatives, I couldn’t find the one I liked.

    Finally I made fast java ORM framework and open sourced it at:
    https://code.google.com/p/fjorm/
    It is quite similar to ActiveJDBC, but I like mine more.

    Hope someone might like it.

  • Tarek Says:

    I agree that new frameworks are available that do a better job and are simpler to use than Hibernate and JPA. I recommend studying and using the one that fits your needs better (I’m using Ebean’s Play! Framework implementation, I really like the ActiveRecord pattern).

    But I disagree when you say Hibernate is not suited for big applications. It’s just that Hibernate focuses on Objects. In order to successfully work with Hibernate, one has do design the database around the objects, not the other way around. We are used to think of database entities and creating the objects to manipulate them in Java.

    I’m not saying this is bad design, it’s just different (and modern frameworks allow that).

    When it came out, Hibernate was great because it cut down a lot of the work that had to be done manually (as you said, there weren’t a lot of frameworks that did it well).

    The SQL abstraction allowed switching the database providers without rewriting queries, in a time where SaaS, SOA and cloud applications were still crawling (so you had to write your application to work with whatever database the clients had a license for).

    Due to its focus on Objects, things that are normal in SQL, such as partial column selections (select firstname, lastname from users), are a nightmare to do with Hibernate (using projections and transformers).

  • Sachin Says:

    I hope one day these so called S/W Architects understand this….programmers have a tendency to insert hibernate wherever they see a database.. :)

  • gaius gracchus Says:

    AMEN, Brother!!!
    This whole movement that thinks “SQL is evil” is just baffling.
    The optimizer code for most modern databases is some of the most sophisticated code on the planet. Why spend a bunch of money on your database engine and then hobble it completely?

    My view of Hibernate and enterprise level relational database engines is this:
    Picture a huge, lumbering semi or tow truck dragging your Lamborghini behind.

    There you have it.

  • john Says:

    You talk a lot of sh*t about Hibernate without saying anything about how much experience you have using it and other similar tools. It’s hard to take anything you say seriously given that I have no idea whether you picked it up once and then just looked around for other people’s opinions and reworded them or if this is based on solid experience and lessons learned personally. This is coming from someone who already doesn’t like Hibernate, so it’s not like I’m in love with it and just looking for reasons not to trust your article.

Leave a Reply