[hibernate-dev] 5.3 finalization plan

Steve Ebersole steve at hibernate.org
Thu Mar 1 14:37:15 EST 2018


In 2 weeks I will be releasing 5.3 CR2.  I waned to start a unified
discussion about the remaining currently unresolved discussions and what
exactly we are going to do for 5.3 mainly in regards to compatibility with
an eye to 6.0



Cache region-name as exposed in API/SPI

This one is a "sneaky" compatibility concern.  When discussing this, it
seems like we had a consensus that the way this should work is for the name
passed in to be un-prefixed.  Unfortunately the current behavior is to
accept the qualified region name.  IMO we should change this.  However,
there is a big danger in that : it would introduce a run-time behavior
incompatibility, as opposed to a compile one, which in a way is worse.  See
the new test I just added to master for examples of what I mean
- org.hibernate.test.cache.RegionNameTest

One option for compatibility is to introduce a new compatibility flag for
this.  Something like "hibernate.cache.region_name_api_prefixed"
(true/false).  Or a better way might be to accept either, and to avoid the
extra perf hit of add a new setting to disallow calls with the prefixed
name.

Also Sanne brought up the idea of ORM simply no longer dealing with prefix
(this is at odds with the current API/SPI calls as tested).

Other thoughts/ideas?


Caching

It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3.  See
the Jira for details.


Statistics (caching)

HHH-11356 redefines how regions and access strategies are structured,
related and accessed.  I won't get too in to the details here (read the
Jira if interested) but that required changes to other code that uses the
SPI.  Most of those are internal and were easy to adjust.  However
Statistics, as a consumer of these regions and access strategies, also
required some changes.  HHH-12323[2] is the Jira for these changes.

Again the see the Jira for details.


Type System

The other major change for 6.0 is the metamodel, type system change.  This
one is pervasive.  All of the strategies to bridge Type and read-by-name /
read-by-position, imo, are not feasible.

The changes in the run-time metamodel are too much to bridge, which is a
complicating factor.  Right down to PersisterFactory.



P.S. where there is already a Jira it would be best if we can keep the
discussions on the Jira itself.


[1] https://hibernate.atlassian.net/browse/HHH-11356
[2] https://hibernate.atlassian.net/browse/HHH-11356


More information about the hibernate-dev mailing list