We are excited to announce the release of 6.0 Alpha1.
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. Each section below breaks down what works, what does not work, what is not yet implemented.
Type system
The change from read-by-name to read-by-position obviously affects the actual calls Hibernate makes to the
ResultSet
. That in turn affects how Hibernate’s "type system" is defined to be able to call the positional
overloads on ResultSet
.
If you write or use custom Hibernate types, this set of changes will not be source nor binary compatible from the previous version. It is unfortunately the one set of contracts where this difference shows through, passing a String versus passing an int. |
Alpha1 contains the initial proposal for handling various "basic value" customizations including BasicType
,
UserType
, @SqlType
, @SqlTypeDescriptor
, @SqlTypeRegistration
, @JavaTypeDescriptor
, @JavaTypeRegistration
.
The descriptors for managed-types and collections have also changed significantly. See RuntimeModelDescriptorFactory
and RuntimeModelDescriptorClassResolver
So far development in this area has focused on supporting:
- basic values
-
fully implemented
- embeddable values
-
fully implemented
- one-to-one
-
supported (see note about "non-aggregated composite identifiers")
- many-to-one
-
fully implemented
- one-to-many
-
implemented except:
-
adding values to an existing collection
-
removing values from an existing collection
-
non-bidirectional mappings using a join table works, not using a join table does not
-
- many-to-many
-
partially implemented
- any
-
not yet implemented
- many-to-any
-
not yet implemented
Known limitations:
-
extra-lazy collection fetching is, for the most part, not yet implemented
-
"non-aggregated composite identifiers" (
@IdClass
) are not yet supported -
post-insert identifier generation (IDENTITY, etc) not yet implemented
-
inheritance is not yet implemented (limited support for discriminator-based)
-
support for
@SQLInsert
,@SQLDelete
, etc not yet implemented
See https://github.com/hibernate/hibernate-orm/blob/6.0.0.Alpha1/design/type-customization.adoc. It is a work-in-progress document describing how to customize Hibernate’s type system and how Hibernate maps values to the database. This document will eventually become a chapter in the user guide.
Generated SQL
We expect the main performance improvement to come from the actual JDBC ResultSet
calls. However, there are
a number of secondary benefits especially when it comes to the SQL we generate.
Since we no longer need the result aliases to be able to read the results, we don’t need to generate them into the SQL.
And given other changes in 6.0 we have better insight into being able to further slim dow the generated SQL in other ways such as avoiding joins we needed to render before.
Also, all of these changes in the generated SQL makes what we send to the database much more concise which improves performance over the wire and performance for the database parser/analyzer. And its just plain easier to read - bonus!
HQL
Hibernate now uses Antlr v4 for interpreting HQL queries. Antlr v4 is significantly faster than Antlr v2, which is what Hibernate has been using up through (and including) 5.x.
We also cleaned up and refactored the grammars to perform better.
Quite a few new HQL language features are planned for 6.0. Alpha1 includes the following:
-
Nested dynamic-instantiations - use dynamic-instantiation as an argument to another dynamic-instantiation. E.g.
select new DTO( a.id, new AnotherDTO( a.name, …. ), … ) …
-
Multiple dynamic-instantiations - mix dynamic-instantiations with other result types freely. E.g.
select a.id, new DTO( a.key, a.text ), new AnotherDTO( a.name, …. ), …
-
Expanded literal type support using JDBC escape-like syntax. E.g.
… where e.startTime < {ts '1999-01-01 00:00:00.0'}
-
Better support for custom query functions. Better, but different - suppliers of custom functions will need to update to the new signatures designed to work with an AST and work with the new type system
Non-HQL Queries
As of 6.0, Hibernate’s legacy org.hibernate.Criteria
support has been removed. Support for
JPA Criteria is not yet implemented.
Support for native queries has also not yet been implemented
Artifacts
All Hibernate ORM artifacts have been moved to a new groupdId - from org.hibernate
to org.hibernate.orm
.
Relocation artifacts are published for each published module
hibernate-envers
has been folded into the hibernate-core
module to provide better integration - easier
and more powerful for users.
hibernate-spatial
, hibernate-ehcache
, hibernate-infinispan
and hibernate-jcache
are
temporarily disabled. And in fact there is some discussion about removing 2 of them completely for 6.0:
-
hibernate-ehcache
- this module supports using Ehcache 2 which I have been told by the Ehcache developers is "no longer supported". But then there was a release just a few weeks ago. :) At any rate, the preferred way to use Ehcache as the second level cache is viahibernate-jcache
+ Ehcache 3. -
hibernate-infinispan
- Integration for using Infinispan as a Hibernate second level cache have moved to being developed under the Infinispan developers. This module already had a relocation published back as far as 5.3
Next step
The plan for Alpha2 includes implementing:
-
Implementing inheritance support
-
Complete association mapping implementation
-
Implementing Criteria support
More information
See the user guide and migration guide.
Also check out the release page.
To get in touch, use the usual channels:
-
hibernate tag on Stack Overflow (usage questions)
-
User forum (usage questions, general feedback)
-
Issue tracker (bug reports, feature requests)
-
Mailing list (development-related discussions)