Slashdot Mirror
Hibernate - A J2EE Developers Guide
What's To Like
The first thing that I liked is the way the book is written. Mr. Iverson has a very pleasant writing style that I found engaging. Not too formal and not too light. Naturally, there is a certain amount of Hibernate evangelism, but hey, if the author doesn't like the tool, then how am I supposed to feel good about it either? The evangelism does not feel like it strays from the bounds of truth, and there is much honesty in his first and last chapters where he discusses reasons for using a tool like Hibernate, and how Hibernate has influenced the design of the soon-coming version 3 of the EJB standard from Sun.
Chapters two, three and four cover the basics of using Hibernate. Each covers a different aspect, and each is independent of the other. Chapter two covers the use of the Hibernate mapping file as the reference that everything else is built from. This is the recommended mode of operation, where the database schema and data access objects are built for you. Chapters three and four are for those of us in the corporate world where the code or the database schema comes first and we have to adapt to and accommodate it.
Chapters seven and nine give the database theory-challenged amongst us a useful refresher in database relationships and transactions. The information, while provided in the context of Hibernate, serves as a useful refresher for the rest of us.
Hibernate has three query mechanisms. Given its relational database capabilities, one of the options is the use of plain old SQL, naturally. The two remaining options are the Hibernate Query Language (HQL) and the Criteria API. The HQL gets a fairly decent amount of coverage and left me to infer that it is the preferred means of expressing queries. The Criteria API gets only four and a half pages of explanation, which is still more than the single page dedicated to SQL.
The next to last chapter is a collection of real-world advice and tips for getting the best from Hibernate. This is a very useful chapter and looks like it contains good advice. The only thing I would suggest is that it's a little slim for a chapter of its own. Either the information could have been tucked in an appendix, or it could have been spread through the book in the form of embedded tips.
Naturally, the book has a website to accompany it.
What's To ConsiderThe book carries a copyright date of 2005 and a first printing date of November 2004. That being said, it should come as no surprise that the version of Hibernate covered is 2.1.2, but at the writing of this review (early April 2005) Hibernate 3 went final. I feel that the majority of the concepts and basic operations will be unchanged, but take this into account when deciding upon a purchase. While it is difficult to write books against the constantly moving target of an open-source or free software project, it is possible. I was involved in the technical review of a number of Struts books and they were challenged with the task of being available as version 1.1 was released. A massive undertaking, but one that they proved doable.
The typesetting seems crowded in this book. I'm not a white-space extremist, but I sure recognise when there's too little. The listings are often multi-page and have a slightly squashed feel to them.
Depending upon your point of view, chapter five is either a very useful annotated explanation of all of the available mappings within Hibernate, or it's a bad case of using available online documentation as filler (53 pages). Personally, I dislike this, but if you're in the market for an "all-in-one" style of book, this might work for you.
SummaryThis is a solid work that will take you from novice to a good working knowledge of Hibernate. If you can live with the fact that the book targets Hibernate 2.1.2 while the current production version available from the website is 3.0, then give this book a try.
You can purchase Hibernate - A J2EE Developers Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm programming Java, bitch!
Hibernate, first of all, is becoming the de facto persistance layer for all modern java webapps. Tied up with the Spring Framework for transactions and either Struts or Tapestry on the front end, it is becoming a commonplace for tons of Java work.
This book, however, I found extremely lacking. It didn't really teach me anything new that I didn't already learn from the webpages. Granted, I've been using hibernate for over a year now and have kept up with the technology, so perhaps this is still a book for someone new to the technology.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Yeah, really, it's not that bad. As a Java programmer, I've come to find out as long as you make sure you don't use more memory than you need (i.e. nulling variables that are no longer useful), things run fine... ...correction. Things run fine so long as you don't use Swing. Swing needs a serious makeover (yes I'm aware of alternatives, but Swing just looks so dang cool when it works)
Before you mod me funny, think, perhaps I was insightfully funny?
I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action. HiA is a great book, written by people who work on the project, including the lead developer. Of course, this review doesn't have much information that couldn't be obtained from skimming through the table of contents on Amazon.
Yours was a powerful, extremely engaging post that I found chock-full of interesting and insightful commentary!!!
Ironically, the word ironically is often used incorrectly.
Is it going to be replaced by C#? Perhaps, but it is possible to fully exploit it today, and with tools like Hibernate it's possible to rapidly deploy applications on a grand scheme. In today's business environment it is often a matter of getting it done fast rather than best, and if it's turning into a problem with performance it is always possible to turn to another language once you have something in place.
I never vote for anyone. I always vote against.
-- W.C. Fields
Actually, this is one technology that kinda lives up to the hype. Its an ORM that performs (in most cases) as fast as hand-written sql statements. I call that powerful and ultra high performance...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I am curious to know if this books spend a decent amount of space on actually using Hibernate in the context of a J2EE application (i.e., instead of using CMP)? I currently work with CMP and I am not a huge fan, I am very interested in alternatives and wonder if this book is the place to start looking.
The title of the book implies that the book does cover this, but the review doesn't actually mention this specifically.
What is the latest on this battle?
There are so many soundbites floating around:
Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.
JBOSS is adopting Hibernate as the underlying persistence mechanism for its Container-Managed Entity Java Beans.
EJB 3.0 rejected JDO 2.0.
So.. now I am confused. Who is the winner? Should I buy the book or not? Anyone care to enlighten us?
High performance? I'm curious, as I'm heavily thinking about shifting from handwritten SQL and the Spring framework to hibernate. I do scientific research, and pull large data sets (.1 - 5M rows) out of a database to operate on.
Often, without carefully tuning these querries, I'm getting horrible performance. With well tuned querries (and appropriate indexing), performace is acceptable. If hibernate was smart enough to say - build anonymous views then join on them when it was a benefit to performance - then I'd be interested. If hibernate was smart enough to aggregate multiple rows of data down to a single row to map onto my summary data objects, I'd be interested. If I'm simply pushing the problem off to another framework, then I'm not sure if it buys me anything over my current methodology.
So, how well does hibernate handle the really complex query work?
if (java.performace >= c.performace) I.eat_hat();
Bleh:
push ax
push bx
push cx
call test_speed_C
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move al,ds:[di+2]
call test_speed_asm
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move ah,ds:[di+2]
cmp al,ah
jb bwahaha_msg
pop cx
pop bx
pop ax
Chicks dig asm, but I'll concede it's so-so for rapid prototyping though...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
If you think Hibernate is good, then try Cayenne and really be blown away.
I am not affiliated with Cayenne at all - just a VERY satisfied customer.
http://objectstyle.org/cayenne/
To follow the usual java method naming conventions, your method should be named performAce(). Also, from a readability standpoint, a method named performXXX() should probably return void. Secondly, any C programmer worth his salt will remove some (but not all) of the vowels from a method name to mark his territory (i.e. c.prfrmce).
Lastly, would you like fries with that hat?
It's simple: I demand prosecution for torture.
The most important unanswered question: does it discuss XDoclet?
I know, many people like maintaining configuration files manually. Some people also like nailing their tongue to flaming coals.
Personally I prefer using a handful of @hibernate and @spring tags. But I haven't found a decent explanation of how to use the tags (e.g., if you use A you must also use B). It can be annoying - I only recently discovered the @hibernate.joined-subclass tag that permits me to use a common base object (for an integrated 'id' space) without creating a "kitchen sink" monster table.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Well, Hibernate isn't an SQL writer. It's for translating between RDBMS and Objects. It's very good at persisting objects and getting objects from a database. It's very good at pulling large graphs of associated objects, which is a pain in the ass to do manually and difficult to do well (for me anyway).
Although it's possible to do summaries, it's not what it's for primarily. I think you'd be better off polishing up your SQL rather than learn Hibernate if that's what you're doing. Not that it would be any worse than what you're doing now (you could run the same SQL through it), it just seems like you could get bigger improvements from the time you'd spend learning it.
For those of us that want a simpler, faster, easier to use framework and just want to map your own queries to objects, is much better. And for those that like .NET it is available in that platform too.
e r);
Here's an example on how to execute a query called "myquery"
MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myinteg
And here is the query declaration:
<select id="myquery" parameterClass="java.lang.Integer" resultClass="mypackage.MyObject>
select * from mytable where id = #value#
</select>
Simple query to object mapping
Open Source Java Web Forum with LDAP authentication
From the Hibernate homepage:
The Hibernate Query Language, designed as a "minimal" object-oriented extension to SQL, provides an elegant bridge between the object and relational worlds. Hibernate also allows you to express queries using native SQL or Java-based Criteria and Example queries.
So...I'm guessing you're using the phrase "SQL writer" in some new and unusual way. Does "SQL writer" mean "writes SQL output to standard output"? Do you mean "SQL optimizer?"
Hibernate can only talk to RDBMSs that use SQL. It writes SQL to them and recieves SQL from them.
Mod me down and I will become more powerful than you can possibly imagine!
The parent is exactly on the mark. The forced separation of deployer/developer roles in J2EE has caused me to do lots of useless busywork since I first started using it back in the 1.0 days. I'm a contractor, and have worked in a bunch of J2EE shops since then -- and not one of them has ever made use of the ability to tweak the sorts of configuration parameters you'd typically include in your XDoclet tags. But until XDoclet started catching on, they all had to endure the development overhead of maintaining separate configuration files and source files.
In addition, the parent is also spot on that using XDoclet doesn't stop you from changing the configuration at runtime! The system still reads the configuration files and they can still be tweaked at deployment time if need be. The only thing XDoclet does is save the developer from having to maintain all those annoying XML files by hand while coding.
If it still bothers you, just think of it as embedding default configuration information into the source. Most applications, I think it's safe to say, do that in one way or another anyway.
And HQL? Wow that's a great feature. Having to learn a mini language that looks almost like SQL and does the job of SQL.
Yeah, but you can't blame Hibernate for that idea. The whole Java world seems to love pseudo-SQL: EJB-QL, JDO-QL, etc.
where there's fish, there's cats