Yesterday, another vendor marketing statement was posted on TSS. I usually
ignore these, but when it is about data management, I just have to reply. What
is always surprising to me is how little we Java developers still know about
data management. Here is a statement made by Maxim Kramarenko in the
Type - not sex, or race - discrimination is what we do when we read a row from a SQL query result set, and determine what Java class we should instantiate to hold the data from that row. Type discrimination is needed by any ORM solution or handwritten persistence layer that supports polymorphic queries or associations.
September 20-22 in Melbourne will be the first time we deliver our new three-day Hibernate course. The course has been heavily revised and expanded to include previews of the cool new stuff coming in Hibernate3 and an overview of Hibernate internals (/very/ useful if you ever need to debug a Hibernate application). There are still seats available, if you're quick! This will be the last training we run in Australia for a while, since I won't be in the country much, if at all, over the next six months or so. Email email@example.com for more information. (We also have an upcoming course in Paris, November 3-5.)
I gotta preface this post by saying that we are very skeptical of the idea that Java is the right place to do processing that works with data in bulk. By extension, ORM is probably not an especially appropriate way to do batch processing. We think that most databases offer excellent solutions in this area: stored procedure support, and various tools for import and export. Because of this, we've neglected to properly explain to people how to use Hibernate for batch processing if they really feel they /have/ to do it in Java. At some point, we have to swallow our pride, and accept that lots of people are actually doing this, and make sure they are doing it the Right Way.
One of the joys of working on an open source project with commercial competitors
is having to implement features that our users simply don't ask for, and probably
won't use in practice, just because those competitors try to spin their useless
features as a competitive advantage. We realized ages ago that it's really hard
to tell people that they don't need and shouldn't use a feature if you don't
We were doing some work with a customer with a very large project recently, and they were concerned about traceability of the SQL issued by Hibernate. Their problem is one that I guess is common: suppose I see something wong in the Hibernate log (say, some N+1 selects problem), how do I know which of my business classes is producing this? All I've got in the Hibernate log is org.hibernate.SQL, line 224 as the source of the log message!
Hibernate3 is now ready for a public test, go get it! It has all (well almost all) features we'll ever need for object/relational mapping, and if it doesn't have it, it's easy to subclass, extend, and implement.
There's been a certain amount of noise recently surrounding simple JDBC frameworks
like iBATIS. I've liked the idea of iBATIS myself, for use in applications which
don't need an object-oriented domain model, and don't work with deep graphs of
associated entities in a single transaction. A JDBC framework also makes good sense
if you are working with some kind of insane legacy database; ORM solutions tend
to assume that associations are represented as nice clean foreign keys with proper
referential integrity constraints (Hibernate3 much less so than Hibernate 2.x).
Just had an interesting discussion on firstname.lastname@example.org, started by David Cherryhomes, which saw me stupidly insistingthat something can't be done when in fact, now that I think about it, /I realize I've actually done it before/, and that even the Hibernate AdminApp example uses this pattern!
Another major change in Hibernate3 is the evolution to use an event and listener
paradigm as its core processing model. This allows very fine-grained hooks into
Hibernate internal processing in response to external, application initiated
requests. It even allows customization or complete over-riding of how Hibernate
reacts to these requests. It really serves as an expansion of what Hibernate
tried to acheive though the earlier Interceptor, Lifecycle, and Validatable