Hello,

Having convinced a number of application groups of the power of Hibernate, we are almost ready to standardize on it across the board for ORM.

However, one stubborn app group is complaining they can't use it due to what they see aa shortcomings:
1) an object can't span multiple tables (although support for this is forthcoming from what I heard)
2) there are some restrictions on FKCs when you're using composite keys, also not null semantics
3) they have existing SQL queries for their business objects, they want to use them and not have to learn HQL (or even use the SQL-like sql expression where you can pass where clauses through)

The main issue is they have a legacy data model (and application) which should be upgraded / parts of it redesigned.

However: they are proposing using iBATIS instead. Could you give me some reasons why iBATIS is not as good. I realize it's more of a DAO framework where you write your own SQL (not a O/R mapping solution at all). But I'm sure there are other things in addition to this including caching, consistent way to specify locking/cache strategies declaratively for classes, outer join fetching.

Any other areas I could add?

Thanks,
Alex

I already implemented this and it is working very nicely in v22branch. Anyway, it is not really such a bad shortcoming ;)



Ummm, no, not really ... all Hibernate functionality is available for composite keys. In some circumstances you might need to implement Interceptor.isUnsaved().

What are you talking about specifically?



Use a named native SQL query.





Well, I don't like to bash on iBATIS, since it is a very useful project and is (a) much simpler than Hibernate and (b) better if you are using stored procedures for everything.

However, iBATIS doesn't implement features like:

* automatic dirty checking
* proper association support (including efficient fetching strategies, transitive persistence, etc)
* caching
* object-oriented queries (with polymorphism, etc)
* dynamic-insert / dynamic-update
* transactional write-behind
* (Does it support JDBC batch updates yet?)
* etc...


So for an application with a complex domain model, and a reasonably sane relational schema, Hibernate will save LOC and most likely perform better. (Also, the application can be very portable between database vedors, if that matters to you.)

But the final choice really depends upon what you are doing. For simple applications, or applications with a really screwy legacy database, or SPs everywhere, iBATIS is a good choice and has an easier learning curve.

Thanks for the detailed response! This will be very helpful...

Use hibernate if your domain model is JAVA code and IBATIS if this model is DB itself (It has meaning if you have more than one client and not all of clients are JAVA applications)

I think if you look a bit more carefully at what you just wrote, you will notice how much less sophisticated this kind of association support, and caching, is than Hibernate's :-)

One of the main reasons for going with a sophisticated "full ORM" solution is that it saves you from the dreaded n+1 selects problem, the biggest performance problem in Java applications today. If iBATIS tries to solve this problem, they will need to transform themselves into something much more like Hibernate. So, in fact, the "association support" you just showed is a performance bug.

And if you don't want to learn HQL, well, just use createSQLQuery() for everything. ;-)

Yes, iBATIS is much simpler than HIbernate, and we recommend it for simple apps. If you have a simple "view on database" app, use it, it will work just great. For truly object oriented applications, you need "full ORM". See Hibernate in Action for a much more extended discussion of this topic, it is still not fully appreciated in the Java community.

P.S. AFAICT, you are just plain wrong in your statement that the caching is more flexible. Hibernate's session + second-level + query cache architecture is VERY powerful.

A first step would be to appreciate that a "light" and a "full" ORM tool are different, and for a reason: each has its uses and place. Use the right tool for the job. Don't look for the "do it all" silver bullet. Woah, this sounds like Bruce Tate wisdom, I better stop :)

Not necessarily. Here's what I think: IB cache is a "global" one, i.e. it lives after the session is closed. Probably, 90% of all associations are lookup tables that rearly change. So, "n" associated object will be simply looked up from cache, hence it should not be more expensive than making a join returning the data over the wire.

Alternatively, one could explicitly write a query with join in IB, if necessary.



One problem is that createSQLQuery() must use a class that has been mapped. I may want to return a list of Dates or an int, etc.


I think that's pusing it a bit (I mean "full ORM", not the book :)). It appeas that book has not been published yet, can you give me a clear hint why you think complex db models need "full ORM".

Our model is not simple but in some cases we still have to use SQL even though we wanted to go with HB all the way. Since we have to use SQL anyway, why not just use iBATIS for everything, that's what we think now.

There is a JIRA use with a feature request. Vote, or better, provide a patch.

more on n+1 selects:

Actually, the picture is even better for iBATIS than I previously described (see above). Autojoin is not always better than sub-select and it's not uncommon to join and pull the child's data but never use it. So, if IB is setup to use lazy loading and cache then 1) no join and data pull overhead 2) when child's data are required then sub-select will hit IB's cache.

So, the bottom line is "n+1 selects" argument does not really show that HB is that much better than IB (if better at all). Considering that IB has rather strong arguments going for its use (see above), HB must also has something, right?

Thanks

P.S.


I just used that example to illustrate that createSQLQuery() may be clumsy to use, as it is now. Obviously, if one uses HB only to run createSQLQuery() then we go back to the original question ... wouldn't it simpler/better/more productive just to use iBATIS?

Sure it would be. So, whats the point? You either want a full ORM or not.

The point is why would anyone want "full ORM" when iBATIS offers what appears to be a simpler, more flexible and more productive solution that works just as well? I'm not trying to bash HB (we're using it now) but I want to be clear about what HB's additional complexity buys me. I went through the Gavin's list (see above) and none of the features presented as HB advantages is really important to justify additional complexity, IMHO.

This is all along the lines "Why use Entity Beans when HB is simpler and more productive, why use HB when iBATIS appears to be simpler and more productive". Thanks

This discussion is really not going anywhere. Please, read Hibernate in Action first, where we clearly and completely define the terms, features, and use cases for "full ORM".

Having "dirty checking" is not something that is "nice", but something that enables you to use a very different application architecture. You might not see this yet. The same is true for other statements you made. We can go on like this for days, but this is not really productive.

I also think that the best way to talk about this kind of thing is person to person, or at least, voice. So, if you want to talk about ORM pro's and con's at this abstract level, meet us at a JUG talk or conference.

Oh, and the solution for the n+1 selects problem is not a process-scoped cache, like you describe. Start thinking about transactions and isolation.