Tuesday, September 4, 2012

My experiences with Hibernate - Part 1

Hibernate is arguably the most popular ORM tool which is not only widely used and well documented but also motivator for other ORM standards like JPA. There is one side of camp which hates ORM in general (championed by Ted Neward in early 2006 and propagated by his article "The Vietnam of Computer Science"). I read that article long way back in 2007 and thought in horror"My God ! Why should I bother about ORM in general. I am happy with my JDBC and cluttering my code with mapping code". But as things turned out, ORM tools slowly gained ground and now a days majority of Enterprise applications use some sort of ORM to speed up the development work. So I begin to have a taste of Hibernate during work and personal projects. Hibernate does a great job when you begin to appreciate the impedance mismatch betweeen object model and relational model it's trying to solve ( though that's impossible to completely solve. To know why read the article mentioned above). Also its well documented and an exceptionally well written book "Hibernate in Action" (now in second edition with title "Java Persistence with Hibernate"). The mailing list is helpful and there are lots of sample examples.
However while advocating Hibernate to anyone I had a feeling inside and I could not give word to that  until one day when I stumbled upon a phrase by ever popular Joel. He mentioned about "Leaky Abstractions" and when I read that I was convinced that is what ORM and in general Hibernate is. In summary what "Leaky Abstraction" refers to is an abstraction which promised to act like an abstraction to its users but behind the scenes requires the users to understand about its details ( which is violation of  the principle of abstraction).
I am not taking away anything from Hibernate and maintain that it a well written tool full of features. But just a word of caution. If you think you just need to know what to use in Hibernate for use case, you will shoot yourself in your foot. You have to keep an eye on what hibernate is doing behind the scene and how to use it myriads of configuration settings. If you do not you will loose several hours in debugging it. I would suggest if you foresee yourself using Hibernate or JPA for a considerable time in your projects, then spend some time in soaking in some basic and advanced concepts from the book "Java persistence with Hibernate". You won't regret this.

I coming weeks I would be listing some of the concepts in Hibernate which are bit confusing and at times misleading. These posts would not be necessarily long ones and some may even be bullet points but they will be helpful to understand more about the inner workings of Hibernate.

4 comments:

  1. I agree that you must know what is hibernate doing behind the scenes, but it's ok, because Hibernate IS NOT an abstraction ! It's a framework. Persistence doesn't hide the database from you, it just save you from writting boilerplate code to bind your data to your objects.

    Besides, even some abstractions require you to know what they are doing. A lot of pain in modern development come from people using APIs without knowing a thing about what's going on

    ReplyDelete
    Replies
    1. I completely agree with you. I usually love to know about the internals of the framework and concepts I am using however My point was that in case of Hibernate I had to be aware too much and in the back of my mind I was always thinking what SQL it must be generating. Having said that, for the task of mapping these two unrelated concepts Hibernate does good job.

      Delete
  2. Detached queries can be way too expensive, I remember a query taking 5 minutes to return!!!

    ReplyDelete
    Replies
    1. I think you mean you had some crud operation over a detached instance and it was taking a lot of time. So then it would be time for looking at the associations of the object and the cascade options. Looks like you had many detached objects and each object had many associations which too needed to be updated. Here you will be forced to examine the type of sql query and the number of sql queries hibernate was generating. More often, you can find some configuration or optimizations to work around your issue. Also there are options of batch operations in Hibernate.

      Delete