Hibernate ORM 4.1.1 has just been released. This release contains a slew of improvements and bug fixes. Some specific changes of interest include:

• Big performance increase in the internal QueryPlanCache class which caused caching of HQL, JPQL and native-SQL compilation to be a bottleneck in concurrency (HHH-5927)
• bunch of improvements to the new 4.1 natural id loading feature, such as the ability to load load by natural ids using persistent inheritance (HHH-7046) and
• Speaking of natural id loading improvements, HHH-7129 specifically may cause issues with applications already using @NaturalId in an unintended. Previously Hibernate had let you define annotations anywhere within an a persistent hierarchy (even spread across the hierarchy). That was never an intended usage of @NaturalId and attempting to do so now throws an exception.
• Allowing JPA static metamodel population to still happen even if model uses non-JPA features such as @Any mappings (HHH-6589)
• Support for custom collection types using annotations via new @CollectionType annotation (HHH-4417)
• On the documentation side, the documentation has all been migrated to DocBook v5 now which is great. A lot of the devguide has been finished out. I am still making the older manual available under 4.1 as well until all pertinent content has been migrated. That work required a lot of coordination between a group of a few of us at Red Hat that work on the DocBook and styling side of things. We work under the group name PressGang, and we could desperately use help. None of us are really design nor DocBook people so-to-say. If anyone is knowledgeable in that area and willing to help out, contact us via our PressGang Google+ group End of shameless plug :)

Speaking of Google+, I just created our Hibernate.org Google+ account too!

See the chagelog for more detailed breakdown of all the changes.

Hibernate ORM 4.1.0 has just been released. This release adds a few new features, as well as a bunch of improvements and bug fixes. Some features in particular include:

• A new (actual) API for loading by natural identifiers. See mainly HHH-2879 and HHH-6974. Additionally, see my earlier post on this feature.
• Addition of a TenantIdentifierResolver for use with multitenancy in getCurrentSession use cases. See HHH-6336
• The ability to provide custom dirty handling. See HHH-3910 and HHH-6998

See the 4.1 release notes for the full details.

Additionally, quite a bit of work went into the documentation for this release. The JPA/HEM documentation has been completely consumed into Hibernate Reference Documentation and Hibernate Developer Guide. Mostly annotation/mapping information went into the former, while everything else went into the latter. Other efforts such as documenting multitenancy, services, etc when into Hibernate Developer Guide as well. The focus now, as we move ahead will be folding the information from Hibernate Reference Documentation into Hibernate Developer Guide.

3.6.10 was released today as well. It contains some bugfixes. Again, see the release notes for the details.

P.S. A quick note about the name Hibernate ORM. This refers to exactly what we previously called Hibernate Core. A brief history is that initially there was just Hibernate, but as the team started working on related projects (Hibernate Search, etc.) we agreed to refer to what had been just Hibernate as Hibernate Core. We recently decided that the core portion of the name was just a bad choice, as it doe not give any clue as to the intent. Hence Hibernate ORM.

One of the new features in 4.1 will be the addition of an actual API for loading entities by natural id. Yes previous versions had the ability to do natural id loading leveraging criteria queries, but that approach was very limiting. The new API will allow caching at both the Session and SessionFactory level in addition to providing a consistent API. The new approach has been made available for identifier based loading as well, again for consistency.

New methods have been added to the Session contract as a starting point (see source or javadoc for additional discussion):

public IdentifierLoadAccess byId(String entityName);
public IdentifierLoadAccess byId(Class entityClass);

public NaturalIdLoadAccess byNaturalId(String entityName);
public NaturalIdLoadAccess byNaturalId(Class entityClass);

public SimpleNaturalIdLoadAccess bySimpleNaturalId(String entityName);
public SimpleNaturalIdLoadAccess bySimpleNaturalId(Class entityClass);

All of the load access delegates have methods for getting an entity reference (getReference) and loading an entity (load). The distinction is similar to the older get and load methods on Session; getReference on load access delegates equate to Session.load and load on load access delegates equate to Session.get

public interface IdentifierLoadAccess {
    public IdentifierLoadAccess with(LockOptions lockOptions);
    public Object getReference(Serializable id);
    public Object load(Serializable id);
}

public interface NaturalIdLoadAccess {
    public NaturalIdLoadAccess with(LockOptions lockOptions);
    public NaturalIdLoadAccess using(String attributeName, Object value);
    public Object getReference();
    public Object load();
}

public interface SimpleNaturalIdLoadAccess {
    public SimpleNaturalIdLoadAccess with(LockOptions lockOptions);
    public Object getReference(Object naturalIdValue);
    public Object load(Object naturalIdValue);
}

So let's say we have an entity defining a natural id:

@Entity
@Table(name="T_USER")
public class User {
    @Id
    private Long id;
    @NaturalId
    private String username;
    ...
}

we can load instances of that class by natural id as follows:

session.byNaturalId( User.class ).using( "username", "steve" ).load();

That actually makes sure we get back an initialized instance, just like Session.get does. If we just want a possibly uninitialized reference we would use this instead:

session.byNaturalId( User.class ).using( "username", "steve" ).getReference();

Since the natural id here is simple (just a single attribute) we can make this even easier:

session.bySimpleNaturalId( User.class ).load( "steve" );

Hibernate Core 4.0.1 has just been released. It mainly contains bug fixes and minor improvements. Check out the release notes for details.

The artifacts have all been published to the JBoss Nexus repository under the org.hibernate groupId. Or if you prefer, the download bundles are available from SourceForge in both ZIP and TGZ formats.

The GitHub repo formerly named hibernate-core will be getting renamed after the 4.0.1 release today. Its new name will be hibernate-orm. The whys have been discussed over the past few weeks in the developer meetings, so I will not go into all that; see the meeting minutes if you are interested. I did, however, want to discuss the ramifications of this rename.

Forks

GitHub manages pointers from the forked repo to its source. Your fork will still be named {username}/hibernate-core, however, even though it points to hibernate/hibernate-orm. As far as I can tell this is fine. You can rename your fork as well if you want; if you decide to follow that path, simply adjust the clone urls as discussed below pointing to your fork in addition to those pointing upstream.

Local clones

This holds true whether the clone is a clone of a fork or a clone of the upstream repo. Essentially you will need to adjust the remote url associated with any renamed GitHiub repo. The way this is done in Git is using the git remote set-url command.

For example, assuming you are trying to reset the url associated with the remote named origin you would execute git remote set-url origin git@github.com:hibernate/hibernate-orm.git