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
andcube
group-by operators -
support for
(not) exists
predicate -
support for
any / some
andevery / 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 specificSqmTranslator
instances used to translate an SQM AST into Hibernate’s SQL AST. -
Dialect#getSqlAstTranslatorFactory
-SqlAstTranslatorFactory
is a factory for specificSqlAstTranslator
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
See the user guide and migration guide.
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/