Hibernate in Action

Adrian Spinei writes "From a documentation point of view, Hibernate is one of the most notable exception in the world of LGPL'ed projects. Its website offers a plethora of information, from solid documentation (the reference has no less than 141 pages) and various FAQs to sample projects and third-party resources. The forum is quite active and you may get answers to tricky questions. Or a little bit of rough treatment in case you haven't RTFM - but that is understandable, given the number of questions that the authors have to answer every day. Under these circumstances, one might wonder what Gavin King (Hibernate founder) and Christian Bauer (documentation/website maintainer and Hibernate core developer) can add in order to be able to write a 400-pages book about Hibernate. I mean - sure - only by joining the reference documentation, different FAQs and guides, one can easily 'extract' a hefty 'manuscript' with more than 200 pages." Read on for Spinei's review of Hibernate in Action.

Hibernate in Action
author	Christian Bauer and Gavin King
pages	400
publisher	Manning
rating	unavoidable
reviewer	Adrian Spinei
ISBN	193239415X
summary	ORM pour les connaisseurs

Well, I am glad to tell you that this is not just a dump of the on-line docs. The book not only gets you up to speed with Hibernate and its features (which the documentation does quite well). It also introduces you to the right way of developing and tuning an industrial-quality Hibernate application. I consider myself a pretty seasoned Hibernate developer, being familiar with the API since its 1.2 version in Q1-2002 (if I remember well the first app when we used Hibernate). However, I was proved wrong by Hibernate in Action, which describes best practices and even API features that were unknown or vaguely known to me. That is, until now.

The first chapter, in the good tradition of all first chapters in the world, is an introduction. It's a very well written introduction about why do we need ORM solutions in OO applications. The chapter explains the O/R impedance mismatch, while declaring quickly that OODB sucks (immature and not widely adopted). Wel'll also find out that EJB also sucks from a persistence point of view (for various reasons). Which can be quite a surprise knowing that Gavin is one of the authors of EJB3.0 specs. Or, on the contrary, this will explain a lot of things in the new EJB specs.

Now that we have cleared the "why Hibernate" issue, let's continue to the second chapter. Which - tradition obliged - is a "Hello, world" and a "Let's get started" chapter. Here you go: almost 50 pages later you should be able to write simple Hibernate-based persistence layers and integrate within an application server, like for instance ... Jboss ! Humm, well, why not ? They are sponsors of the Hibernate project, after all.

In the 3rd chapter, our fresh knowledge will be put to good use by starting the development of an online auction application called CaveatEmptor. This app will follow our reading progression and will grow bigger and smarter chapter by chapter. But for the moment, we are at the inception phase. What gives: a little bit of analysis, a stylish class diagram of the domain model and the resulting mapping file. And if you thought (based on 2nd chapter) that the mapping file is very intuitive and simple, you're in for a big surprise -- it is, indeed, intuitive and simple! Quite bizarre for an open-source project. As a matter of fact, the mapping file is one of the pivotal elements of Hibernate, since it addresses directly the O/R impedance mismatch, a recipe for transparent linking your POJOs and the constrained relational model. No wonder that a big part of this chapter is aimed at explaining why and how the mapping works in Hibernate. You'll see how class associations and inheritance translate at the metadata and mapping level. You'll start to understand the things that you took for granted in the previous chapter and you'll have that pleasant "uuh, I see" chain reaction. Hold on, it's just the beginning.

Because chapter 4 is going to explain once and for all the lifecycle of persistent object in Hibernate, their behavior from a persistence point of view as well as the available fetching strategies. And if you thought you already knew everything by heart from the documentation ... well, maybe you do know everything by heart. Nevertheless, it's very well synthesized in chapter 4 and I'll recommend it anytime to a coworker eager for Hibernate knowledge.

In the next chapter (the 5th) the rollercoaster slows down a bit. That is, if you already know the behavior associated with the four possible isolation modes in transactions, what are the different types of locking, what (the hell) MVCC means and the importance of transaction scopes. Chances are you already know some of this stuff quite well, but everybody needs a refresher from time to time, especially when it's well explained and when it comes with versioning and caching (1st and 2nd level) in Hibernate as a desert. By the way, I thought that OSCache supports clustering, not only SwarmCache and JbossCache, as stated in the book. There's even a thoroughly explained example of using JbossCache as a level 2 clustered cache for Hibernate, but it shouldn't be too hard to convert to other types of caching systems.

Now, if I were the author of the book, I would have placed chapter 6 before chapter 5. But I am not the author, which is quite fortunate for you dear readers since Christian and Gavin are much more competent than me at writing books about Hibernate (and probably at some other unrelated domains). They have decided to go back to mapping in chapter 6, after the short transaction/caching intermezzo. Well, they should know better... it's time for a serious dose of advanced mapping. This chapter is attacking interesting subjects such as custom mapping types (simple or composite) and (finally) the mapping of collections. Special guests stars: the whole gang of "sets, bags, lists and maps", together with explanations about their relational equivalent (associations, associations and associations !). Oh and yes "polymorphic association" (section 6.4.3) - I wasn't even aware that Hibernate is able to do that... guess I'm not that 'seasoned' (as a Hibernate developer) after all.

The 7th chapter is about "Retrieving objects efficiently" : about 45 pages for the 'retrieving' part and 6 pages for the 'efficiently' part. Fair enough ! You'll learn how to master basic HQL queries (parameters, pagination ...). You'll get a grip on the query by criteria API, as well as on advanced stuff such as dynamic queries, filters, subqueries and native SQL (very powerful). At the end of the chapter there's the Hibernate-specific solution for the n+1 selects problem, query caching and result iterators.

Following this wealth of useful knowledge, the 8th chapter starts a bit dry. Nevertheless, after a short introduction about Hibernate in managed environments, you'll find yourself again in the land of advanced programming techniques : application-level transaction implementation ! This is mostly new stuff (at least for me) - a great collection of best practices for transactional behavior management in industrial-quality apps. Somewhat unrelated but still interesting, the chapter ends with legacy schemas integration and a smart implementation example for audit logging.

The 9th (and last) chapter is about the round-trip development in Hibernate using the classical toolset : Middlegen and/or hbm2java and/or XDoclet. All the available techniques are presented in a very detailed, step-by-step manner.

Wait : don't close the book, there's more ! Ignore Appendix A (a short and rather uninteresting document about SQL fundamentals - that is, if you know SQL). Appendix B contains mildly un-fascinating ORM implementation strategies pour les connoisseurs (come on guys, I'm just a dumb user). But - Appendix C is a great collection of real-world stories and by all means read them all ! Especially the last one, a treasure of hard to find knowledge (no spoilers, please...).

In the end, I have to confess that there is something truly interesting about Hibernate In Action : albeit very technical, it reads astonishingly easy - and this kind of books is unfortunately very rare nowadays. My congratulations to the authors for this excellent piece of work - it was worth the wait.

As for you dear potential reader, if you already know all the information detailed in the book, I bow before you, great Hibernate wizard.

---

You can purchase Hibernate in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

What is Hibernate ?

[a3217055]

What is Hibernate and what does it do ? I think the article failed to mention that can anyone please tell me what it means.

Johnny English

What the hell is Hibernate?

[Anonymous Coward]

Perhaps if you told us the purpose of the program/project in the first few lines, we might continue reading.

What is it?

[DaHat]

It always drives me nuts when I see a story about a given software package that talks about it's greatness... but that does not simply say what it is. This is made worse when the it's homepage which I'm sure describes the given package is /.ed.

book better than review, I hope

[Russ Nelson]

I hope that the book is better than the review. The reviewer starts off with the most basic assumption that ANYBODY with a CLUE knows EXACTLY what Hibernate is. Perhaps that's why hibernate.org isn't responding right now, because everybody read the top story, found no description of Hibernate, and clicked on the hibernate.org URL as the most likely place to find a description of Hibernate.
-russ

Re:What is Hibernate ?

[FosterKanig]

That has to be the worst summary I have ever seen. Tell us what the fucking thing is.

Curious why there's not more.

[Amiga Lover]

I think it's interesting there's not more really exceptional documentation for F/OSS projects.

OSS Coders tend to have the fantastic attitude of always improving whats been written before, of making it better & better, revising, patching, rewriting, until an application becomes so damned useful there doesn't seem to be any other realistic choice.

All well and good when it comes to coding - but where are all the documentation geeks to do likewise?

Re:Hibernate is good, but I am using Prevayler mor

[pcraven]

I still prefer directly writing the SQL code myself. It doesn't take that long, and for many things it seems to be more efficient. I only pull the fields that I need.

I have seen many applications where a developer will pull a list of objects out of a database and only use a small percentage of what was pulled. This was caused by a heavy persistence layer abstracting what was happening, and a developer that didn't care to find out.

I seem to be in the minority with this view though. Automated persistence is quite trendy.

Is there a doc in the house?

[Doc Ruby]

When people release source under L/GPL, you'd think they'd want people to use it, and contribute back. It's really hard to do that when the code is inaccessible for lack of documentation. Even reading code that is commented (a rarity) is no substitute for an overview - relying on "grep" is no way to trace codepaths or marshal APIs. At least CVS requires a note on checkin, even if it's usually a vague "fixed bugs". If you're not going to write your code starting with a first pass of all comments, with clear, consistent variable names, at least include a description of each code file's function in the grand scheme in its header, and usable README and INSTALL files for the whole project. Most important, have someone not on the design/code team read the docs for usability by a stranger. Beta testing the docs isn't hard, and you get to gloat about your brilliant achievements in words that don't have to compile.

Re:Curious why there's not more.

[Anonymous Coward]

Because writing code is a) fun, b) is relatively easy, at least for the sort of stuf you're talking about and c) scores you ego points. Very few people are willing to write documentation for fun. It's a thankless chore.

Re:Hibernate is good, but I am using Prevayler mor

[tanguyr]

nonsense, no human mind is capable of dealing with the immense complexity of SQL. Why, databases were just huge excel spreadsheets until smart OO developers figured out how to store... i'm sorry, of course i meant "Persist" objects in them. And don't forget the rallying cry of the modern developer: "the database is the bottleneck".

/twisted & bitter

Sufficient docs rare?

[ajs]

Hmmm, *looks on hard drive*...

a 7000-word document on configuring ALSA drivers
a 400,000-word document on using MySQL
a 700,000-word documentation set for Perl (just the core, not counting add-on modules)
6.5MB of Kernel docs
27MB of Gnome help ... the list goes on, of course ...

Nope, that's not a particularly outstanding trait. If he had talked about this documentation being well integrated with other, related documentation-sets, then I'd find that interesting (rarely is this the case in open source software), but it doesn't sound like it is.

The overview tells us nothing

[frovingslosh]

Another lame /. article; what supposedly is an "overview" tells us nothing and is so full of TLA and such that you have to know what they are talking about to even make any sense of it. Clue for timothy: If you're introducing something new in a lead page /. article, it would be nice to actually tell people what it is, cutting through three letter acronyms and other buzzwords that can only be understood in context , which is missing when the reader has no reasonable expecation of knowing what the hell you are talking about!!!

So, I'm the only one, huh?

[tokachu(k)]

I thought "hibernate" was a power-management function.

Actually, this entire article is proof of how...

• ...program names are getting more pointless by the day (Hibernate?), and...
• ...how most programs are mostly hype (more buzzwords than a Dilbert book).

I'm sorry, but there's no excuse for the utter disregard to using common sense that was exhibited in the "hibernate" developers' group. People wonder why Microsoft can sell shoddy products. Well, I'll tell you why: they give them meaningful names (Word processing: WORD, Development studio: STUDIO).

To the people at hibernate.org [hibernate.org]: you should be ashamed.

Re:Hibernate is good, but I am using Prevayler mor

[Fnkmaster]

No offense, but the Prevayler site is pretty lame. I'm quite sure it's fast, but anybody who's written an in-memory system before knows that. Whenever your working data set is small enough to fit in memory, and your transactionality requirements force you to serialize processing at the application level anyway, your performance will be much better with a simple object-in-memory design.

Anyway, the point is the site doesn't do anything to elucidate the limitations on ACID compliance, querying capabilities, etc. that you would expect from an object database system. Hell, they don't even seem to recognize that Prevayler is just a limited subset of an object database system (i.e. a memory-resident one). I'm glad somebody has written a reusable chunk of code to do this and all, but I wish the people doing it were more aware of the theory behind databases, and what trade-off decisions they were actually making so they could better document and explain them to their users.

Anyway, if you are just comparing it to MySQL (hehe) I'm sure there are lots of great use cases for Prevayler, but when you compare it to a real RDBMS and look at real enterprise application usage scenarios, it's a bit of a different situation.

Re:Hibernate is good, but I am using Prevayler mor

[BJH]

Hahahaha. Good one ;)

Don't forget, many modern developers haven't yet figured out that abstraction and performance are in an inverse relationship.

MOD PARENT UP

[hopethishelps]

This article just seems like a bunch of open source NewSpeak,

You're right, there is no information in the article. It doesn't even tell us what Hibernate is. The blather is also peppered with undefined acronyms - ORM, POJO, HQL.

And some idiot moderator modded parent down as a troll. Sigh. It's not a troll, it's a valid and accurate criticism of a really crap article. Crap is, unfortunately, becoming the Slashdot-article standard.