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.
{ 10 } Comments
Andrew, I stumbled across your blog via DZone. From the title of the post(s), I expected something more serious. All your rants, however, seem to be a product of you being too quick to code before reading the documentation.
Hibernate will produce the output of what is wrong with query in its ERROR log. Parsing errors will include the character number where the error occurred. Along with the exception itself, it is always enough to pinpoint the problem.
Somewhat of an issue here, though, is that when using @NamedQuery annotation, entire text of query will be concatenated into one line; making it more difficult to spot the problematic place.
Still, it is very easy to setup a Hibernate Console plug-in in Eclipse, and test all queries interactively, before writing them in your code.
> An error in a query will often cause all your tests to fail. Not just ones that use that query.
I don’t see a problem here. All tests fail because SessionFactory can’t be built for each one of them – because named queries are evaluated during configuration. What kind of behavior would you expect? Isn’t it better for Hibernate to fail-fast in this situation, since you surely won’t be deploying queries with errors in production, would you?
Maybe Hibernate must provide a configuration to enable/disable checking named queries on initialization. But, actually, I really like this feature (because I get the errors sooner).
Kind Regards
The log will have the details since there can be multiple errors which is not easily captured in a stacktrace.
Sounds like *you* swallowed the stack trace, or perhaps did not look far enough down it. I’m sure you’ll find the underlying error a bit further down the stack trace. FYI, exception wrapping is a *good* practice, not a bad practice.
Thanks for the tips regarding the error log. I’ll look into this when I’m back at my office. Perhaps I’ve been spoilt by using Guice a lot recently, which goes out of its way to tell you where you screwed up, and how, and often how to fix it.
But — do you still get the error log details when you get an NPE from the HQL parser, as mentioned in the next rant and here:
http://forum.hibernate.org/viewtopic.php?p=2401637
I’m sceptical to be honest, but I’ll test it and see.
Regarding the fail-fast or fail-on-use question, I guess this is a subjective issue, but from a unit-testing POV it feels a little bit weird seeing completely unrelated tests fail.
I’ve been using Hibernate for several years and I really like it. But with the coming of EJB3 and other company’s JPA implementations, I think it could be abandoned in two or three years.
Angel Pinazo
Smart Soft Solutions
http://www.tresese.es
Only one? There are many problems with Hibernate.
1 HQL
2 XML
3 Lousy generic support
4 Lousy Performance
5 Huge distro
6 Hides the database which is the most important part of an app.
etc.
etc.
@Dan
1. HQL – what is wrong?
2. use annotations.
3. Really? I am not having problems.
4. Usually because the developer modeled in correctly.
5. So?
6. LOL. too funny. It is an important part but not the center of the app universe. If it is for you, then you have a major architectural issue.
Unit testing? Why are you hitting the database for your unit tests? You shouldreally be mocking out the Hibernate stuff anyway. Consider it an opportunity to write better unit tests.
Brandon
Brandon, perhaps unit-testing wasn’t the right phrase, but I certainly have JUnit tests that bring up the Hibernate session in order to test that it’s working as advertised.
Fortunate really, since it turned out that it wasn’t — see #2 in this series for one or two examples.
Post a Comment