Comments on: Hibernate pitfalls part 1

By: Qiang

Qiang — Fri, 22 Aug 2008 17:55:10 +0000

I tried to like hibernate but I finally gave up. It was really a painful to use it in my projects. The main reason I think it is too intrusive. It dictates the way you design your application. It blurs the boundary between database and applications. Database schema inevitably leaks into application’s data model. The result is, if you change either data model or database schema, you have to change the other. And because hibernate’s hbm is so complicated, changing database schema will make it painful to update the hbms. At last, Hibernate has too many caveats. You have to be very careful when writing beans for hibernate.

Instead, I found it was a pleasure to use iBatis as I had full controls over SQLs and my code was much more concise.

By: Raveendran

Raveendran — Mon, 23 Jun 2008 18:37:55 +0000

I think, the points discussed here are worthwhile. I don’t know if hibernate is good or not but I was trying out something simple like this

HibernateTemplate ht = getHibernateTemplate();
ht.save( b );
ht.flush();

and this resulted in all those mysterious errors that the article talks about.

I would definitely not prefer Hibernate over simple C++ or over the great ORM capabilities of Ruby on Rails. At least we have complete control of the exceptions and errors in the case of C++ or RoR. That way hibernate sucks, not even a good post in net for this problem from the Hibernate team and above all the team tries to defend themselves for their follies.

By: John Newman

John Newman — Thu, 15 May 2008 21:45:13 +0000

“Hibernate sucks because I don’t understand anything about transaction boundaries”

hibernate is good stuff if you aren’t too lazy/incompetent to figure it out. Spring’s hibernate template & hibernate transaction manager are a big help.

By: Jiang

Jiang — Sun, 30 Dec 2007 01:31:01 +0000

In my view, Hibernate is for people who don’t know or don’t want to invest time in writing performant SQL queries. Maintain and convert a Hibernate project is very painful in that you have no idea how the queries are executed.

By: Rajeev Jha

Rajeev Jha — Tue, 04 Dec 2007 10:45:39 +0000

I have used hibernate and frankly there are few hidden monsters. Best of all the documentation is good and normally you get answers to all the questions. I would consider write-behind to be a feature and not an *issue*

By: Arvind Kumar

Arvind Kumar — Sat, 07 Jul 2007 08:22:11 +0000

Nonsense or Not, this article ( part 2 and 3 as well) helped us in our project where we were not considering the flush() much. I think people at hibernate.org should come out with some standard list of mistakes or misconceptions that a consultant/contractor/developer can have.

By: Peter D

Peter D — Mon, 02 Jul 2007 23:03:30 +0000

Mark — I don’t know if this is a proper answer to your question but here’s something I ran into today … we are converting data from a legacy system into a new system with business objects persisted with hibernate. The query against the old table, also H defined, returns 26,000 objects … everything is running really slowly. 80 seconds to process 100 entries. Queries are taking forever. CPU is running 50% and the db is hardly working up a sweat. The solution? Clear the Hibernate cache immediately after the query bringing in the old table’s objects and clear it every 100 entries written to the DB. Now it takes 8 seconds to process 100 records. The problem is I would have expected H to just take care of this for me. It is not obvious (to me) that this needs to be done.

I don’t necessarily agree with the thrust of this post but I think it and its replies are quite educational; so thanks to the author for writing it.

By: mark

mark — Tue, 15 May 2007 05:00:32 +0000

Is this statement true????

“Debugging is tough and error handling in hibernate leaves a lot to be desired. If you make mistakes or have a complex database, hooking up hibernate can be a nightmare and cause your project to go way over budget.
“

By: Rob Bygrave

Rob Bygrave — Thu, 12 Apr 2007 10:51:37 +0000

Perhaps this is slightly off topic, but in I’d like to see how this relates to JPA as well (as opposed to just Hibernate).

The way I see it, this example shows what I consider 3 specific issues with JPA (as it currently stands). Specifically I would personally like to see JPA provide more control to developers in 3 areas.

1. Control over Statement Batching (on/off, batch size, generated keys)
2. Control over Cascading of Persist/Delete (the ability to turn it off)
3. Better support for using Raw JDBC Support

The example here as I see it revolves around the ‘transparent batching’ that is occurring (until the ‘flush’ in this example). As I see it there is nothing in JPA that allows you to control the statement batching - It may be that vendors do not see your pain?

Another weakness in JPA (as I see it) is the lack of support for getting the Connection and using it (for more advanced uses such as stored proc calls, savepoints etc). Normally a query would implicitly flush (in JPA, Hibernate and Ebean) but raw use of Connection is not supported in JPA (currently).

Disclaimer: I’ve created Ebean at http://www.avaje.org to try and improve JPA (and simplify life).

By: Brian Pontarelli

Brian Pontarelli — Tue, 10 Apr 2007 17:01:29 +0000

The problem here is that this example is running into some side effects of CMT (container managed transactions). Hibernate is working *correctly*. In fact, flush() is limited in when it can force a database commit. Itâ€™s limited by the containerâ€™s transaction boundary.

This code was actually run command line without any container. Hibernate batches all database activity until a transaction boundary is hit and this is the pitfall I describe here. You just have to know this and plan for it.