Software is too expensive to build cheaply...

It can be pretty useful to supply dependencies to domain objects that you're loading via Hibernate. This is where Hibernate Interceptors come into play.

I'm now working on my second project with Hibernate, having delivered the first, and I'm playing with some of the features I didn't have time to figure out last time. And I have to say: named queries rock, big time.

A while back, I blogged about how Hibernate named queries rock. I found another reason why they rock today: it lets you hide what your persistent properties are called.

I'd introduced a Hibernate user type into the code base a few days ago. I'd based it on an example in the (more or less) wonderful book Hibernate in Action. Naturally, however, I'd copied the example with a bug in it!

I gave a talk at the AJUG-QLD tonight on the new features of Hibernate 3.0. Here are the slides.

Somehow I missed this new feature in Hibernate 3.0.

When I gave my talk on Monday, I'd sort of hurried over the new bulk queries in Hibernate, largely because I didn't have much luck finding doco on them.

Now I know how they work.

I finally got a chance to try out upgrading to Hibernate 3 at work. It wasn't the smoothest of rides, but I got there in the end.

In Hibernate 2, you could sort-of do a bulk delete via the Session interface. In Hibernate 3, they have true bulk deletes, ala Section 3.11 of the EJB 3 Persistence API. However, they have some significant differences which people migrating to the new functionality need to be aware of.

At work, we are a heavy user of ehcache. Well, we would be... it was initially written at Wotif, to overcome problems with the Jakarta JCS project. I recently had to sit down and figure out exactly how it works, and thought I'd take a moment to write it up.

Update: I tested the Hibernate serialization behaviour. See below for more.

I was checking over my web stats recently, and I noticed a trend has emerged solidly over the last few months: most of the search terms that lead to my blog are about Hibernate. Of my top 20 search terms, 11 were about Hibernate, and I'm in the Google top-10 for most of those terms (somewhat surprisingly...). Now, I'm not talking hundreds of search hits, but I am talking more than dozens.

All up, and at this time, I've written ten articles on this site about Hibernate, in various depth. To make life easier for people who are looking here for Hibernate-related material, I've added a Hibernate sub-category (underneath the Java category), and put those articles in it.

Caveat: I am not a Hibernate guru. I don't even play one on TV. I'm merely a Hibernate user who has taken the time to write up things he has found out or thought about. No accuracy is assured, though I will happily accept corrections.

Hibernate has extensive support for caching built in (well, provided by various plugins, actually). This caching means that potentially expensive database operations can be avoided, especially in smaller apps (ie, non-clustered, which actually can go to quite a large size).

Most people who use Hibernate caching are used to having object instances cached. Hibernate can also cache query results. However, there are some things you need to be aware of when you do this.

When working simply with Hibernate, you end up coding to concrete classes. This violates the idea that you should program to a type, not an implementation. It also means that various things you tend to do with Hibernate (like writing getters and setters) end up "polluting" your domain classes.

There's a common idiom in Java for writing the equals() method. Straight from the classic book, "Effective Java", it looks like this:

public boolean equals(Object obj) {
  if (this == obj) { return true; }
  if (obj instanceof ThisClass == false) { return false; }
  ThisClass other = (ThisClass) obj;
  return this.importantField1.equals(other.importantField1) && this.importantField2.equals(other.importantField2);
}

When using Hibernate, particularly with lazy proxy classes, it's important that you stick to this idiom!

Hibernate has long had a feature known as "query caches" - you can run a query, cache the result, and thus avoid running it repeatedly. The only problem is that it doesn't do what you think it does.