biotext.org.uk

I hit upon a snag today — while PostgreSQL requires that certain maintenance commands (e.g. vacuum analyze) are executed outside of a transactional context, it’s actually quite hard to get at Hibernate’s underlying database connection directly. Each Session object has a connection() method which returns a JDBC connection object, but this actually turns out to be a Hibernate-generated proxy for the real connection object, which refuses to work outside of a transaction.

You can probably get around this by using autocommit mode instead of explicit transactions, but this is a configuration property that affects your whole application, and is considered harmful.

Eventually I hit on a really dodgy workaround. You can manually rollback the transaction at the start of your SQL statement the old-fashioned way:

<sql-query name="nasty.hack">
<![CDATA[
rollback transaction; vacuum analyze;
]]>
</sql-query>

This also works when used with the prepareStatement() method as shown here.

Frightening but effective. If you know of a better way, let me know!

Andrew.

Hibernate is supposed to allow you to write queries and manipulate data in the normal Java idiom. Which is true up to a point, and that point is almost five years in the past, when Java introduced generics.

Generics are absolutely standard practice in Java these days, and have been for two (nearly three) versions. But Hibernate still doesn’t support them, despite lead developer Gavin King saying at the time:

We will also need to support Java generics, which basically boils down to allowing typesafe collections (which is very trivial).

Nearly five years later, this still hasn’t happened, and you still need to manually cast the results of queries and liberally add @SuppressWarnings("unchecked") to demonstrate that you’re aware you’re doing things a bit wrong.

Andrew.

There are several other posts in this series. Please read the disclaimer before you write an angry reply.

Unfortunately, open-source projects above a certain size seem to become victims of their own success.

Many other excellent OSS products like Guice or CXF have user-centred mailing lists that the developers also read. These developers are generally very willing to help out with problems, and the users — having been treated kindly when they started out — are equally keen to help with the areas that they have experience of.

Hibernate has no user mailing list, just a large forum site that’s easy to ignore. Mailing lists encourage people to respond because queries drop in their inboxes; forums tend to be visited in times of need, and people are probably less likely to drop by for philanthropic reasons.

As an example, I’ve posted three queries (plus one repost and various followups) in the Hibernate forums over the course of a month, politely and with plenty of information. Despite hundreds of views, and the fact that two of them highlight features which don’t work as described, not a single reply from anyone else has been forthcoming. Not even a one-liner saying “bad question, RTFM” or “working as designed” or “known bug”.

Maybe this is sour grapes, but the amount of community feedback from other OSS projects puts this to shame.

Andrew.

There are several other posts in this series. Please read the disclaimer before you write an angry reply.

On the Hibernate website (and elsewhere), one of the touted advantages of Hibernate over roll-your-own SQL is:

Hibernate Core for Java generates SQL for you, relieves you from manual JDBC result set handling and object conversion, and keeps your application portable to all SQL databases.

Well, not exactly. Many functions in HQL (Hibernate Query Language) are simply passed through verbatim to the underlying database engine, without any modification.

This is normally fine, but on my first ever HQL query I tried to use a natural-logarithms function — which is log() in HSQLDB (my testing server) and ln() in PostgreSQL (my production server). Which means that queries written to target the production environment fail with a charming NullPointerException in the test environment. Half a day’s debugging, right there.

More worryingly, imagine if I had innocently written the query using log(). All my tests would have passed. Then I would have deployed the application to the production environment, and it would still have worked, but all the queries would have happily returned the wrong answers — because log() in PostgreSQL means base-10 logarithms.

Hibernate not only fails to insulate you from dialect differences like these, it also introduces a false sense of safety by pretending that it does.

Andrew.

There are several other posts in this series. Please read the disclaimer before you write an angry reply.

The first in a series of missives on the subject of Hibernate.

Disclaimer: I’m not out to bash Hibernate, nor do I fundamentally dislike it. In fact I think it’s an impressive piece of work, which is why I’m bothering to highlight some of its pitfalls, in the hope that this saves other people the hassles I went through, and perhaps gives its maintainers something to think about. If I didn’t think it was worth investing the time to do this, I’d just drop it and move on.

When there’s a problem with an HQL query, all the exception says is:

“Errors in named queries:” and then the query name.

Gee, thanks. Even ‘1970s technology’ RDBMSs give more specific error reports than that. By quite a long way.

Actually, you only get this error if you’re lucky — if you’re unlucky you get something even less helpful.

Oh, and reason #1a:

An error in a query will often cause all your tests to fail. Not just ones that use that query.

Andrew.