We are excited to announce the release of Hibernate ORM 6.0 Alpha5.

The main design goal for 6.0 is to improve even more Hibernate’s through-put performance. High-load performance testing showed that Hibernate’s approach of reading values from ResultSet by name to be its most limiting factor in scaling through-put. At its most basic, 6.0 is all about changing from its old strategy of read-by-name to read-by-position. But that simple goal has a lot of ramifications.

We have come really far, but still it is an Alpha, so there is still plenty more to do.

Mappings

We continue to develop support for the new read-by-position paradigm in the various aspects of the mapping model. Alpha5 specifically added support for:

  • @Version

  • @EmbeddedId

  • Composite foreign-key

  • FetchMode#SELECT for to-one associations

  • Polymorphic collections

  • arrays

  • sorted Maps

  • ordered Maps

  • sorted Sets

  • ordered Sets

  • @SortNatural / @SortComparator for sorted Sets and Maps

  • quoted column names

  • EntityGraphs

  • Fetch-profiles

  • Filters

  • @Where / @WhereJoinTable

  • Database export, update, etc

Improved basic value mapping

In terms of how Hibernate sees basic values, they break down into:

  • a SqlTypeDescriptor

  • a JavaTypeDescriptor

  • a BasicValueConverter

  • a MutabilityPlan

Alpha5 adds the ability to easily customize these parts individually using annotations to control which SqlTypeDescriptor, JavaTypeDescriptor, etc get used.

We’ve started a documentation chapter discussing this, although it is very young:

HQL improvements

  • support for rollup and cube group-by operators

  • support for (not) exists predicate

  • support for any / some and every / all qualifiers on RHS of comparison operators

  • support for sub-queries in the select-clause

  • support for insert-values HQL queries

  • support for insert-select HQL queries

  • support for update HQL queries

Dialect improvements

Historically Hibernate defines its Dialects as static information - meaning every database + version combo needed to to be accounted for as a distinct Dialect class. We’ve been wanting to make Dialects a little more flexible and decided 6.0 was the right time to do that.

Dialect initialization

Dialects are now initialized with information about the underlying database, including version. The exact information is defined by DialectResolutionInfo which is very similar to JDBC’s DatabaseMetaData

Dialect SQL influencing

Dialects have been given better control over "improving" the SQL generated by Hibernate to optimize for that database at various levels of translation:

  • Dialect#getHqlTranslator - HqlTranslator controls translating an HQL statement into its own Semantic Query Model (SQM) tree (AST). The SQM AST is also the one used by Hibernate to represent the JPA Criteria tree

  • Dialect#getSqmTranslatorFactory - SqmTranslatorFactory is a factory for specific SqmTranslator instances used to translate an SQM AST into Hibernate’s SQL AST.

  • Dialect#getSqlAstTranslatorFactory - SqlAstTranslatorFactory is a factory for specific SqlAstTranslator instances used to translate an SQL AST into an "executable" JdbcOperation

A Dialect is given a chance to influence all three of those translations, although most Dialect implementations will focus on Dialect#getSqlAstTranslatorFactory, if any.

SQM functions

The SPIs related to functions in HQL and Criteria have stabilized, though still considered incubating. These SPIs allow adding custom function capabilities to HQL and Criteria. See:

  • org.hibernate.query.sqm.function.SqmFunctionRegistry

  • org.hibernate.query.sqm.function.SqmFunctionDescriptor

More information

Also check out the release page. Join BinTray and watch the release repository for notifications of releases

To get in touch, use the usual channels as discussed on https://hibernate.org/community/


Back to top