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”.
February 11th, 2013 at 23:28
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.
February 12th, 2013 at 20:53
or even ebean which gives you both sql and orm and has been around for years.
February 12th, 2013 at 22:01
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.
February 12th, 2013 at 22:15
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.
April 22nd, 2013 at 13:24
If pure SQL queries are wanted, then Spring JdbcTemplate is really nice:
http://static.springsource.org/spring/docs/3.0.x/reference/jdbc.html
May 20th, 2013 at 16:33
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.
May 26th, 2013 at 00:20
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
June 17th, 2013 at 02:42
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.