[hibernate-dev] 5.3 finalization plan

[Scott Marlow]

On 03/01/2018 02:37 PM, Steve Ebersole wrote:
> 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?

Will the different cache providers need to get the cache prefix from the 
session factory instead?

> 
> 
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>