Hibernate Hell

[Vinnie Jenks]

I think I've reached a boiling point where I'm no longer interested in Hibernate after weeks of dead-ends and frustrations.

Is iBatis a better alternative? I don't mind writing SQL, really, I rather enjoy it...anything is better than arm-wrestling hibernate's config files to *try* and get the results I want.

I'm very comfortable w/ JDBC and RDBMS - would someone like myself be better off w/o Hibernate?

Sorry if I'm coming off w/ attitude, I'm not saying Hibernate is a bad product...I'm just not sure it's a good product for *me*. I've read Hibernate in Action from cover to cover and even though I understand the *concepts* they've laid out in the book...I'm having a horrible time using it in simple real-world applications. It just isn't saving me any time...there are too many nuances, gotchas, and tedious tricks to make it productive...for me anyhow.

So...iBatis? I've heard good things. I've heard JDO is harder, in which case..mmmm...no thanks. If that's not true, give me your opinions, please! What are the major differences between JDO and Hibernate? I've read that EJB3 will be based on Hibernate (for ORM functionality) - in which case...that's rather unfortunate IMO.

What's the general consensus? I'd rather not hear a defense of Hibernate...I've gotten to know it quite well and I just don't think it's what I'm looking for.

Thanks!

[Leticia Barbalho]

When I started my webapp, using struts and hibernate, people told me not to use struts because it would be soooo hard. But I was surprised, 'cause struts gave me no problems: Hibernate was the one to not let me sleep. After some terrible hard days, which already meant project delay, I finally got the hang of it. If you have already made your mind, good luck. If you won't mind rethinking, I think you might as well keep trying.

[Mark Spritzler]

That's a bummer Vinnie. I thought you had started liking Hibernate.

I love it, and it saves me ton of time. But I am not defending it against you.

I think in your case I would stick with just JDBC. Pulling in a product like IBatis or JDO that aren't as popular makes maintenance and finding people later on more difficult. I always think about the future when you aren't there and someone else has to come in and change or fix something, and it uses a product that most people won't know.

Mark

[John Mikhail]

I never used iBatis, so can't comment on that. Regarding JDO, I think JDO is hanging on, but it's never going to gain any traction to make it an EJB/Hibernate competitor.

At my previous job, I helped build a code generation tool from UML, and the code we generated was based on the JDO specs (not entirely 100% JDO). This was back in 2000. Since then, I haven't seen any real big push from the JDO camp. But even if it was a bit more popular, I'm a little hesitant about having my class files mangled by a post processor. I'm sure it works fine, but it's just a preference. If you decide to go the XML config route for JDO, then how's that much different from Hibernate?

Just curious though...what problems are you having with Hibernate? I agree getting comfortable with it takes a while. I'm still constantly referring back to the reference manual for little things.

[Vinnie Jenks]

Mark, I want to like it...I really *do*...I'm just finding that I have to design my applications around the limitations of Hibernate vs. the framework being transparent...as it should be.

My biggest issues are:

1. Fetch depth is basically hard-coded, you can't specify this when you query so your queries are either way too much or too little for what you're trying to do...if you're using joins and such.

2. Left joins are used in the place of inner joins by default - the only way around this is to use a funky HQL query to join the objects and the results are an Object array...not very flexible...I'd like to be able to use inner joins as easily as outer joins are in mapping files.

3. To get unique results you're forced to use a HashSet instead of a List in your domain objects...otherwise you have to code around it inside of your app...which is tedious and ugly.

4. It isn't simple to just return a single field or a select number of fields in an object like you can w/ a SQL query...sometimes I just need to populate form values w/ smaller amounts of data...Mark...you posed a solution for that a while back but again...you were designing *around* Hibernate...shouldn't have to do that w/ *any* framework.

I've also had some bizarre problems filtering data by a date...but I'm unfamiliar w/ mysql (which I used for this particular app)...but when I query directly, passing a long for the date (using Date.parse) - it works fine. In Hibernate this bombs w/o much of an explanation. I've hit dozens of little things like this that make it insanely frustrating at times.

From what I've read of iBatis - I'd just be hitting the same type of roadblocks, perhaps more.

I sure hope we see some simplicity in future versions of Hibernate. Since it has become part of the EJB3 spec, perhaps things work work out for the better? Given the past of EJB, it could even get worse...who knows.

In the end, what is most frustrating about Hibernate is that you can spend just as much time troubleshooting and configuring your objects as you could have just spent writing queries and manually mapping your domain to your data...the workload is just shifted to another area of your project.

-v

[Christian Bauer]

"1. Fetch depth is basically hard-coded, you can't specify this when you query so your queries are either way too much or too little for what you're trying to do...if you're using joins and such."

There is no "hard coded fetch depth" in Hibernate, you can fetch any graph you like with the minimum number of SQL queries. Your statement is too vague to go into more detail about the problem.

"2. Left joins are used in the place of inner joins by default - the only way around this is to use a funky HQL query to join the objects and the results are an Object array...not very flexible...I'd like to be able to use inner joins as easily as outer joins are in mapping files."

Sorry, but inner joins don't do the same as outer joins. There is a reason why outer joins are used for eager graph loading. An inner join would not retrieve all the objects. If you get an Object[] back from a Hibernate query you simply didn't specify a SELECT clause or a Projection (Criteria). This system _is_ flexible, if used correctly (and its the same as in SQL, really).

"3. To get unique results you're forced to use a HashSet instead of a List in your domain objects...otherwise you have to code around it inside of your app...which is tedious and ugly."

I don't really know what you mean here, certainly "results" from a query have nothing to do with the collection design in your static domain model.

"4. It isn't simple to just return a single field or a select number of fields in an object like you can w/ a SQL query...sometimes I just need to populate form values w/ smaller amounts of data...Mark...you posed a solution for that a while back but again...you were designing *around* Hibernate...shouldn't have to do that w/ *any* framework."

Well, since it seems you don't use SELECT or Projections, it probably is difficult to select only the things you want in a query. Again, this statement is very vague and I don't know what else to answer.

Frankly, I've seen many people try to learn Hibernate and see how they make progress. I'm sorry to say that you are possibly trying to do many things at once, too quickly, and at the same time you are skipping some of the basics. Don't blame the tool if this approach doesn't work.

By the way, you can use Hibernate just like iBatis if you think that will be easier. Check this blog entry and the new StatelessSession in Hibernate 3.1: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/08/23#customsql

[Vinnie Jenks]

    Criteria c = s.createCriteria(Directory.class)
      .add(Restrictions.eq("IsDefault", true))
      .createCriteria("Attributes")
      .setProjection(Projections.projectionList()
      .add(Projections.groupProperty("DirectoryID")));

To make a long story short...the Directory domain object has a collection called Attributes. Each Attribute has a DirectoryID getter/setter. In this case I get this error:

Frankly, I've seen many people try to learn Hibernate and see how they make progress. I'm sorry to say that you are possibly trying to do many things at once, too quickly, and at the same time you are skipping some of the basics. Don't blame the tool if this approach doesn't work.

What basics might I be missing, in your opinion? I could code an entire application w/ Hibernate if I map a single object to a single table...and select my data out table-by-table using the PK/FK relationships...and it works swimmingly! However, it can get very messy, very fast when trying to limit the amount of code you're writing by mapping collections for some of the data.

I think this is where most new Hibernate users come to the conclusion that "Hibernate is only good for small projects". I don't think that's true...I think Hibernate could scale to any size application and probably handle just about any type of problem thrown at it...but at what cost? You may very well spend a great deal more time tweaking Hibernate and futzing around w/ configurations than you would have just using another approach.

I'll tell you what...If I could just figure out a simple approach for mapping collections...using a Set or whatever else might be necessary...I'd be content...because I could just finish this *simple* application I'm trying to write w/o any more marathon Hibernate study-sessions.

Damn the performance considerations...just this once, just for this discussion...rough and outside of best-practices would suit me just to get some clarity.

I can do the mapping and get unique results using a HashSet but I can't *sort* the data...as HashSets aren't sortable...there's no guarantee of order. I can use a List but I end up w/ a ton of duplicate records as there is no guarantee of uniqueness like I'd get w/ a HashSet.

What's an elegant way out of this conundrum? Am I missing some magic here? Dazzle me Christian!!
[ October 23, 2005: Message edited by: Mark Spritzler ]

[Christian Bauer]

You still don't seem to understand the difference between an outer join and inner join. It has nothing to do with duplicates.

If you load Orders and all their LineItems, you can use an inner or outer join fetch. Both results contain duplicate Orders, as each Order has potentially several LineItems. The difference is simple: With an inner join, only Orders that _have_ LineItems are retrieved. With an outer join all Orders, with or without LineItems, are included. That's why you'd almost always use an outer join for eager fetching of object graphs, unless you really know what you are doing.

Your statement about "duplicates in a fetch=join mapped collection" is... wrong. Hibernate does not do this - in fact, it would break all Hibernate applications if true. My guess is that you are confusing queries and mappings. As you haven't shown any code or mapping, its impossible to figure out what you are missing exactly.

For the rest of your posting I don't have the time to elaborate. If you don't want to continue hand-waving about your problems, I suggest you visit the Hibernate forum and post the required information (code, mappings, etc.), so somebody who has more time can have a look. Don't name your posting "Hibernate Hell" though.

If you are comfortable with breaking data independence, by all means, use an object database. A nice side effect is that when the software breaks down in a few years, I get paid to migrate it to a real database

[Mark Spritzler]

Weird.

Vinnie, I apologize, but I have no idea how it happened, and I tried to recover the first part of your last post.

I edited your post because you accidentally added a CODE tag when you wanted a QUOTE tag, so I changed it to QUOTE. With the CODE tag it made the thread's formatting very long.

But after I only changed that the first part of your post was no longer there. I tried to hit the back button, but it wasn't there either.

It was that part about lazy loading setting.

Mark

[Mark Spritzler]

Christian, thanks for your time and trying to help out, we really appreciate it.

But your statement about Vinnie not understanding Outer versus Inner joins is a little harsh.

When it comes to database stuff, Vinnie completely understands the difference between the joins, in database terms. What he might not understand is the necessity of Hibernate using Outer Joins for data loading purposes. That is fine.

Vinnie, I feel for you, and wish you the best.

Mark

[Christian Bauer]

When it comes to database stuff, Vinnie completely understands the difference between the joins, in database terms.

Since you (or someone else) deleted his statement about "inner joins avoid duplicate records from the driving table", which is clearly false, nobody can tell. But I assure you that inner vs. outer join is a common problem for many people, surprisingly. Even the authors of Hibernate Quickly didn't understand it and tell readers to use inner joins all the time for eager graph fetching (they promised to fix this in errata). To repeat it a last time: the type of join makes no difference for the presence or absence of duplicate information. The difference is in the inclusion of data in the result that doesn't match the join condition, if an outer join is used. No Hibernate at all, basic SQL.

Other misconceptions that came up in this thread, about collections, sorting, query results, distinct projection, etc. are basic things in any database application, not related to Hibernate. By the way, you can write a complete application without ever mapping a collection. The only association mapping that is really needed is many-to-one. Every collection mapping is a conscious design decision you make, for convenience. If it is not convenient, don't do it. Use an explicit query (which, in Hibernate, behave exactly like SQL).

Also, I've only replied because "Hibernate Hell" is not something I'd leave uncommented in any forum. Repeating over and over what I explained in ample detail in thousands of pages of documentation already is however not something I can spare more time for, so I'm out of this thread now and back to writing more documentation... hoping that someone reads and understands it.

[Mark Spritzler]

Thanks Christian.

Trust me, no one wants Vinnie to love Hibernate more than me.

I have developed database applications for over 13 years, and a tool like Hibernate is a god send. Good thing the team, especially Gavin are such geniuses and understands exactly what we do and need.

Mark

[Vinnie Jenks]

Christian,

I can assure you that I understand what an inner-join is and how it differs from an outer-join. I'm aware that duplicates are possible in both cases unless "distinct". It would be *extremely* convenient if there was a *simple* internal mechanism to allow the developer to declare the List collection distinct & free of empty values. I don't see an *easy* way to get distinct results w/o writing my own sql. I read your book, I can't find a single example of how to do this w/ QBC. I realize that I probably have not articulated my particular issues as well as I could have. Mostly it is a matter of displaying data...I'm assuming all those blank records I'm displaying on a page are because of the null data being pulled from the outer-joined table...maybe not...I've been wrong before.

I have not been back to the Hibernate forums for issues because the attitude from yourself and others has been extremely poor. Christian, I appreciate the help, I really do, so please don't take my criticism the wrong way. You guys have a tendency to get very defensive and the Hibernate forums become very condescending at times. I'm quite positive I'm not the only person who's had this experience there.

I realize that you're just trying to help and that newbie users are lame and tend to get frustrated...but that's just par for the course. I don't care to discuss that matter any further and again since it is far off-topic. I thank you for your time...I'm sure you're very busy, please don't waste any more time on my little issues!

I called my thread "Hibernate Hell" because that's where I was/am - after weeks of frustration over what I would think would be simple issues to solve, I popped - I'm certainly not the first. If you don't like it, you could always ignore morons like myself and better spend your time doing what you do otherwise.

Mark, you're great, thanks for all of your help. Quite a bit of my post was trimmed out and I don't remember everything I said...oh well, no big deal. Originally I came here to get people's opinions of other products - not support for the issues I've had w/ Hibernate. It wasn't to bash Hibernate either...I thought I had made that entirely clear but I'm not sure Christian fully understood this.

I think I can use Hibernate for some of the apps we're building...like I said - it's very flexible when mapping a single class-per-table...and saves time over doing it manually.

I think Christian is wrong about object databases and I'm convinced they're quite "real" - they do have a place in the market and I suspect they'll catch on - perhaps more in the "hybrid" space of the market. In the case of db4o - as long as Java and .NET are around...there would never be a need to bring in a consultant to port the app over to a "real database." I'd imagine that is many years beyond the life of the applications we're building. Also, db4o being open source is very likely to ensure it will be around for a while...and thrive.

Thanks for the help all!

[Christian Bauer]

Dude, you repeat again some "distinct duplicate" thing that just doesn't exist. If you query with a join fetch, you get duplicates. No "distinct" clause will make this go away. You don't have to write your own SQL for that, because the SQL is no different than HQL or QBC. It's the same. I think you are looking for "new HashSet(q.list())", if you want to make an (inner|outer) fetch join result distinct from an object graph perspective.

[Christian Bauer]

I have not been back to the Hibernate forums for issues because the attitude from yourself and others has been extremely poor

Oh yeah, and I'm out of here now. Last time I was called an "ass" for helping someone. Now my attitude is "extremely poor". Ignorance is king.

[Reza Rahman]

I would agree with Vinnie...there is definitely something gravely wrong with Christian's tone and attitude towards a fellow developer that deserves nothing short of due respect. I had no trouble understanding what Vinnie was saying. It is unfortunate that a co-author of "Hibernate In Action" did.

There is no great defeat in admitting Hibernate is not for everyone and not for every situation (no man-made tool is).

I am happy the good people who are moderating this board ae keeping the JavaRanch spirit of friendliness alive.
[ November 09, 2005: Message edited by: Reza Rahman ]

[doug parker]

In the end, what is most frustrating about Hibernate is that you can spend just as much time troubleshooting and configuring your objects as you could have just spent writing queries and manually mapping your domain to your data...the workload is just shifted to another area of your project.

I agree. But I don't think hibernate would have lasted as long as it has if it was garbage, so every once and a while i work the examples given in articles on the popular rags. maybe one day i will use it in a real project.

[jay vas]

I agree that Hibernate is impossible. Have you guys looked into Butler ?
Im learning it for some bioinformatics autogenerated apps i need to build.

It is the opposite of hibernate - its all about mapping tables into objects instead of objects into tables.

The idea is to cut the layered crap and allow the model classes of an application to understand the relational database schema below - a violation of the hibernate mantra of transparent persistance --- which is totally impossible.

I gave up on hibernate after 5 days of frustration and confusions.

[Paul Clapham]

You only spent 5 days on Hibernate? It took me at least a couple of weeks before I was at the point where I could react intelligently to things not working out right. Now I'm fine with it. Certainly not an expert but when I want to get something done I can do it.

[Mark D Christiansen]

I just ran into the same problem Vinnie was talking about with duplicates and joins. I was retrieving a REQUEST object which is joined to a collection of APPROVAL objects using a JOIN because I didn't want Hibernate to execute N + 1 queries for N REQUEST objects. When I started getting duplicates I suspected I was doing the query wrong in Hibernate but when I executed the SQL generated by Hibernate it was obvious that the SQL result set was returning duplicate REQUEST rows for every APPROVAL row (each APPROVAL row is unique for the REQUEST). It makes sense, but it would be nice if Hibernate was smart enough to compensate for this issue. I could sort the objects out myself afterwards, but it makes for ugly code.

I have been using Hibernate for about six months now and while you do run into problems initially (especially when you mix in Spring), I more and more comfortable with it and I really like the performance and flexibility I have with my applications. In other words, I think it is worth the effort to learn it. Five days is not enough time unfortunately to master Hibernate.

I can't speak for Christian, but I think this is what he was saying. On another note, I don't know about Christian's other posts, but this one did not seem to be as arrogant as you portray it to be. He seemed like he genuinely wanted to help on Vinnie's issues and for that we should be appreciative.

[Mark D Christiansen]

I tried Christian's new HashSet( query.list() ) solutions for retrieving unique object graphs for a SQL query that returns non-unique result sets and it works exactly how you would want it to work. It surprised me a little. I would have expected that if I have a REQUEST object that is joined to a set of 3 APPROVAL objects when the list is generated I would get three REQUEST objects with a APPROVAL object attached to each request. This is not the case. You end up with 3 REQUEST objects with a set of the same 3 APPROVAL objects on each one. Theerfore when you change the list to a HashSet, the duplicates are removed and everyone is happy. In Vinnie's defense this is not a well-documented solution but I did find it in the Hibernate Forum.

http://forum.hibernate.org/viewtopic.php?t=951244

[Jignesh Patel]

I am using hibernate from last 7-8 months. When I started I too don't like it. But the more I am exploring, I am amused with the facilities provided by hibernate. It has reduced my lot of hours of development.

I do agree hibernate may really have some issues, but then when I worked with Struts it also have some issues that�s why JSF or even in broader range Spring (ie. Spring pageflow) are there. I believe at some point any software has some limitation or may have some bug. It supposed to work in some direction but it gives result in other direction.
People who have worked in Java1.0 and 1.1 they knew, how slow and problematic it is compare to version 5.0.

But then it is a quality product and that�s why it has replaced VB from everywhere when it was at its peak and force Microsoft to come up with C#(Another optimized version of Java).

I would say Hibernate is the same kind of quality framework. If you able to manage for few issues or limitation of it, overall it�s a great framework. After couple of months you just love to use hibernate.

Christian,
I request you to continue helping people. I believe at your level one or two discomfort does't affect when other thousands are in favor. I always keep handy "Hibernate in Action". You must not go out from.

Oh yeah, and I'm out of here now. Last time I was called an "ass" for helping someone. Now my attitude is "extremely poor". Ignorance is king.