Over the past few months we have been adding some simplifications to
the way you can use and specify native sql queries in Hibernate.
Gavin even blogged about some of them earlier , but I thought it were about time we brought some more news on this blog about it.
Steve just committed a new interface and extension point to Hibernate Core. We can finally plug-in custom Session context management into Hibernate. For those of you who already know getCurrentSession() in Hibernate 3.0, this new extension enables the same without a JTA environment.
Hibernate 3.0 is the world's most sophisticated ORXM (Object/Relational/XML Mapping) solution. Hibernate3 makes it easier than ever before for Java applications to interact with persistent data, allowing a single definition of the transformation between various in-memory representations of the entity data and the relational schema, even in the case of very complex legacy schemas and schemas for historical data or data with visibility rules. Hibernate3 also provides the most comprehensive object/relational query functionality, with three full-featured query facilities: Hibernate Query Language, the newly enhanced Hibernate Criteria Query API, and enhanced support for queries expressed in the native SQL dialect of the database.
We just released Hibernate 3.0 beta 1. I've no time to list all the many changes
since the alpha was released four months ago, let alone everything that is new in
Hibernate3, which has been in development for over a year now.
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
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).
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
Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level. What's a pre-defined filter criteria? Well, it's the ability to define a limit clause very similiar to the existing where attribute available on the class and various collection elements. Except these filter conditions can be parameterized! The application can then make the decision at runtime whether given filters should be enabled and what their parameter values should be.