Patrick Peak

+ Follow
since Aug 23, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Patrick Peak

This may not be your exact problem, but try to avoid using concrete collections in your method signatures. Hibernate will end up replacing them under the covers with its own collections for dealing with things like lazy loading. So instead of

private HashSet files = new HashSet();
public HashSet getFiles();
public void setFiles(HashSet set);

change it to

private Set files = new HashSet();
public Set getFiles();
public void setFiles(Set set);

Note that you can still start out with a HashSet as the default (for a transient object) but you can't count on it once Hibernate starts managing the Object.
Nick also wrote a Hibernate Tutorial a while back as well. You can find that here
Here is a direct link to the Table of Contents for the book -

Short answer 456 pages, 11 chapters + the appendix.
We do cover Spring in Chapter 7, the title of which is "Organizing with Spring and data access objects". I'm a big fan of Spring's integration with Hibernate and think they compliment each other very well.

We cover using the HibernateTemplate, which is Spring's wrapper around the Session, handling opening and cleaning up the session, parsing database specific error messages to create an Exception hierachy (classes like DataIntegrityViolationException and OptimisticLockingFailureException).

We also cover using Spring to configure the Hibernate SessionFactory and datasources, as well as how to connect your DAO's, which can use Spring's layer supertype, HibernateDaoSupport. That class provides an easy connection to the SessionFactory with some useful convience methods like releaseSession(Session) and getSession().

Much of the discussion in chapter 7 aims to show why Spring is useful by implementing a DAO without Spring, then refactoring to show how much less code the Spring DAO actually requires.
I haven't really dug into the new parser enought yet to do a valid compare and constrast. I suspect it won't matter much for projects started with Hibernate 3.0, if anything giving more meaningful error messages.

The one time it could possiblybe an issue is when updating a project with lots of existing HQL from 2.0 to 3.0. Nick ran into this a bit while writing the book I believe.
Hopefully both. I use Hibernate on a daily basis, so I wanted to write a book I would pick up and refer to. While we aimed the book first and foremostly at new developers, we wanted to make it useful to developers as a reference. Let me highlight an example of both.

For experienced developers, a useful chapter will probably be the Appendix, "The Complete Hibernate Mapping Catalog", which is designed as quick reference for possible mappings, complete with java classes (with XDoclet tags), ER diagrams, class models and sample mapping documents.

It allows you for example to say "I want a Bidirection Set, what does that mapping look like". So you open the guide and you get everything right there from start to finish.

For newer developers in chapter 7 we discuss Data Access objects. Many more experienced developers have already seen this pattern around, but developers new to Hibernate may not know how to apply it to Hibernate.

We start with a naive implemention of a Hibernate DAO, pointing out it flaws, then slowly refactoring it throughout the chapter, eventually using a Spring based AbstractDao, to demonstrate how much coding that particular project can save you.
The book approaches data modeling really from the same approach that we (the authors) approach it. We don't really do much discussion about the indepth theory of data/ER modeling either. Hibernate in Action has, in my opinion, already sufficiently covered the ORM theory ground.

Most of the examples we work from are Object->Database. We start with the object model, then generate the mapping schema and database tables. Obviously, we need to impose some sort of sanity and not do crazy irrational and poorly normalized database schemas, but from our perspective as non-DBA's it seems to work pretty well.
The basic question is "What are you trying to test?"

1) Is your HQL written correctly?
2) Are your objects mapping correctly?
3) Your actions (or whatever) that use DAO's (which happen to do Hibernate stuff).

For 1 and 2, you need a database really. Hiding the HQL away in a DAO is a good way to solve #3. Having a DAO allows you to stub in a dummy DAO that just returns the objects you want, without the need to go to the database.

We actually wrote a whole chapter about this in Hibernate Quickly, which might be useful.
One thing I forgot to comment on is the performance issue. One of the main reason I started using Hibernate is that it has a huge # of options for tuning the database queries.

Hibernate Query Language (HQL) is much much much more expressive that EJB's query language (EJBQL), at least in EJB 2.x. With HQL you can do single row selects, outer joins, and all sorts of other tricks that EJB didn't let you do. I wrote more about the possiblies of tuning in an article for the serverside here

Admittly, this is a Hibernate vs. Ruby On Rails comparison. Rails has yet another ORM model, though very different than EJB.
[ August 24, 2005: Message edited by: Patrick Peak ]

I think the number examples are one of the main selling point. We try to incrementally build code samples that introduce new concepts. Our core focus is teaching folks that are new to hibernate, while putting in enough advanced stuff for folks who have been around it a while (mostly integration and reference-y type material).
Also, if you are using Spring's HibernateTemplate (which I have done in some of my projects) you need to change their packages to use the new Hibernate 3 classes. The old Hibernate 2.1 is covered in


while the new stuff is in


This means there are 2 HibernateTemplate classes


So don't just blindly autoimport (in IDEA for example) without checking the packages first.
There are actually two questions there I think.
1) How does Hibernate compare to other Object Relational Mapping tools.
2) How does Hiberante compare to other JDBC wrapper tools, like iBatis/Spring/Commons DB.

My personal experience with other ORM tools is limited to Jakarta's ObjectRelationBridge, which I used before Hibernate. At the time (several years ago), we had a lot of problems with it due to lack of documentation and trouble tuning it to be really performant.

We starting using Hibernate and really haven't looked back, so I'm not really sure how OJB evolved. Hibernate is probably the most popular opensource ORM and while popularity isn't always a great indicator of technical elegance (i.e. Struts), I think its well deserved in Hibernate's case.

As far as JDBC wrappers like iBatis, I think they can do much of the same jobs as an true ORM. I've heard good things about iBatis, but haven't had the oppurtunity to use it on a project yet. If you don't have a complicated Object model, or you have a lot of SQL tuning experience/legacy SQL code, a tool like iBatis could probably useful.
We don't cover all the topics, specifically we left out some of the more advanced topics like the Criteria Query API and Interceptors. We do have a heavy emphasis on teaching beginners Hibernate, but we certainly are as short/light as say the O'Reilly Developers Notebooks series.

The first 1/2 of the book covers the basics, while the second half focuses on integration with other projects/libraries, including webframeworks (Webwork, Struts and Tapestry), XDoclet and how to unit test hibernate code.

So I think there is a lot of unique material that folks who already have experience with Hibernate should find useful.
Glad you like it. The internal debate about the title only exceeds the debate about the possible cover designs.
I have to feign ignorance at some level about the contents of professional hibernate. It came out not to long before our book was released, so I haven't had much time to do a comparision.

So I can only really cover things I think we did well. In addition to being a very gradual introduction, we do a lot of 'example by refactor', where we introduce an example, then improve it by refactoring, explaining why things were changed, and gradually adding new concepts. I personally think this really helpful for teaching concepts to new folks.

In addition, I think our coverage of XDoclet is really indepth, and our appendix, which is an example-based quick reference to all the common mappings you can do with Hibernate, has gotten some really good marks from folks I've shown it to.

Our goal was to gradually ramp up developers as they learn Hibernate, and then provide a solid day to day reference for it.