Hibernate in Action 220
| 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.
Hibernate is good, but I am using Prevayler more (Score:5, Informative)
However, for my Java consulting business, Prevalyer [prevayler.org] is definitely my new "secret weapon". With a little care, it is easy to set up your POJO classes so that you can add class attributes without breaking your persistent Prevayler object store. Using Prevayler reduces development time. Good stuff.
By the way, if you've never heard of Hibernate... (Score:5, Informative)
Hibernate is an API for Java that uses Java Beans (get() and set() methods for all properties) to create, read, update and delete rows from a database. It's really cool. It's sometimes called JDO (Java Data Objects) but it's a dangerous association because of the Sun Reference Implementation of JDO, which is its own specification. Hibernate is different.
Re:What is Hibernate ? (Score:5, Informative)
Re:What is Hibernate ? (Score:5, Informative)
Re:What is Hibernate ? (Score:4, Informative)
This was grabbed off www.onjava.com:
Hibernate will help us to painlessly store the data in permanent storage without too much hassle about choosing the kind of storage, installation, or configuration. Hibernate allows us to store any kind of objects; therefore, our application does not need to know that its data will be persisted using Hibernate. Of course, everything mentioned here can be applied in the opposite direction: fetching already prepared objects from a storage is now nearly trivial. Updating and deleting data is also available.
Judging by their inaccessible website, Hibernate is what they do best.
Re:So what is it? (Score:3, Informative)
I've been using this for quite a while, coupled with Spring [springframework.org] you can write a lot of robust reusuable objects, if you utilize java's OO design methods.
Re:Hibernate? (Score:3, Informative)
Re:Hibernate is good, but I am using Prevayler mor (Score:4, Informative)
Also: with Hibernate, you do have control over how much of a row of data you actually retrieve since you specify the mapping that you want in an XML configuration file.
Do try Prevayler however: for some applications it really is a great tool. I especially like it for web applications where most data access is read only: caching objects in memory really speeds things up.
Best thing since sliced bread (Score:5, Informative)
Okay, I haven't RTFA, but the poster should also have made mention of Spring, which works hand in hand with Hibernate. Spring basically is an Inversion Of Control (IOC) framework, that allows you to define Hibernate transaction and session contexts. Spring also offers a great MVC layer, but one does not have to use that. If one chooses to just use Spring as an addition to Hibernate, one can look at Spring's additional functionalities as needed. Spring also offers Oracle BLOB/CLOB support by offering a customized OracleClobHandler - Oracle ONLY supports its propietary CLOB objects and won't accept java.sql.Clob objects via Hibernate.
Generally, Hibernate is very non-intrusive and gives you the opportunity to write JDBC code alongside with your Hibernate code (which is super-elegant and abstracted the way it should have been done a long time ago). So, it can be slowly folced into an existing project without having to refactor any legacy code.
The Hibernate user group is a bit rude to be quite frank - I've tried to post some questions in the dev group and got pretty angry replies. The 'beginner' group was not very helpful, so I had to google for answers. Of course there's the book, and I would strongly recommend to get it, since it is one of the major revenue sources for those Hibernate contributors. We want open source, but we can't expect to get everything for free, right?
My first exposure to Hibernate was through the Appfuse framework [raibledesigns.com], which is an excellent J2EE kickstart project, complete with ant built, Xdoclet, Hibernate, Spring, the works. I was even able to use XDoclet tags inside my Java beans, relieving me of having to write my Hibernate definition files by hand! It really doesn't get much easier than that. For anyone wanting to give Hibernate/Spring a try, I recommend to download the latest version of appfuse and give it a try - it's a liberating experience. The biggest kick I got was being able to seamlessly switch my project from Oracle over to MySQL by simply changing a few environment variables - I mean, how cooler can it get?
Re:What is Hibernate ? (Score:5, Informative)
Actually, it does matter which comes first. Hibernate works best (best defined as most clean, simply) if you have the luxury of a well normalized schema where every table contains a surrogate key. Obviously, if you're working from a clean sheet this is an worthy design choice, relatively easy to satisfy.
However, if you are working with a pre-existing design and you can't retrofit surrogate keys, you're in for a lot of additional leg-work with Hibernate. Getting Hibernate to function with composite keys forces extra coding and imposes limitations. This was my experience 9 months ago when I had a look at Hibernate for an "enterprise" application that must work with vendor schemas.
I don't fault Hibernate; persistence is hard. Mapping an object from RAM to relational storage is much easier when you have a simple 1-to-1 relationship between objects and integers. Working well only with simple surrogate keys is not unique to Hibernate by any means. In principle you're correct; it doesn't matter which comes first. In practice, if you're dealing with composite keys or any form of denormalization you're in for a lot of pain.
Re:Hibernate is good, but I am using Prevayler mor (Score:3, Informative)
"I went into this knowing very little about ORM, and even very little about databases. One of my first tasks was to go out and buy a book to learn SQL properly. All my understanding of the problem comes from what our users have taught us over the last two years."
Sigh... basing a product on secondhand experience from users who probably have never even learned what the relational model is really about.
Re:I am a tad surprised (Score:3, Informative)
It sounds like this may come as a complete surprise to you, but not everybody is a Java programmer. Why should non-Java programmers be expected to know about a Java-only tool?
Hibernate (Score:1, Informative)
Re:What is Hibernate ? (Score:3, Informative)
Hibernate is tempermental at best and broken at worst. The biggest problem is it has it's own special language called HSQL which gets converted into SQL at runtime.
HSQL is supposed to be database neutral. However, things don't work the way they are supposed to all the time. Specifically CLOB/BLOBs on DB2 for OS390 crash the OS390 JVM. Other things fail (sometimes silently) in unexpected ways. I suspect alot of the problems I have with hibernate are due to the fact that it's hard for most people to access a JVM running on OS/390 talking to DB2 on OS/390. Because of that hibernate apparently has little/no testing against that environment.
Hibernate has more features than JDBC but in the end you still have to build out your real persistence layer code to handle all the parent<->child relationship things in your object hierarchies.
I already have programs that will take a database schema and create the domain, broker and standard SQL statements for JDBC based persistence layers. Hibernate doesn't save any development time for me. And anyone else that has been doing java for a few years probably has the same sort of tools and it won't save them any time either.
However, if you were starting from scratch, in an environment heavily supported by Hibernate it probably would not be a bad choice to go with.
Just don't think it will magically do all the hard things like tracking updated/deleted/new objects, cascading auto generated keys from parent to child (or child to parent if your tables swing that way) or sequence delete/update/inserts to avoid referential integrity problems.
-Jerry
Re:What is Hibernate ? (Score:1, Informative)
Re:Why hibernate? What's hibernate? (Score:3, Informative)
I hope that helped.
Re:So if it takes a few weeks to learn... (Score:3, Informative)
Re:What is Hibernate ? (Score:2, Informative)
Usually, problems with mapping existing database schemas to Hibernate arise from the shorcomings of the database and not Hibernate. Oracle's CLOBs and BLOBs are a good example of this, as the methods exposed by the JDBC interface do not work properly and methods from Oracle's CLOB and BLOB classes must be used directly, breaking transparency and forcing the developer to do additional work.
i.