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.
Cedric beat me to this, but if you missed his announcement, the EJB 3.0 second early draft is available. The most interesting new stuff to me is:
We just released the brand new Hibernate Annotations module as an alpha version. This module provides the Hibernate facilities to declare Hibernate O/R mapping metadata through JDK 5.0 metadata annotations (instead of XML mapping files or XDoclet preprocessing). We have implemented the EJB3 (JSR-220) O/R metadata annotations defined in the early draft 1 of the spec. This set of annotations covers all common mappings cases.
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.
It happens sometimes that a domain model objet dettached from a previous session needs/can be reattached without trigging an UPDATE (whether it has optimistic locking or not). Hibernate supports this kind of feature by providing:
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 discussion thread:
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 firstname.lastname@example.org 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 have it.