[hibernate-dev] 5.3 finalization plan

[Steve Ebersole]

My preference is for the providers to handle that, yes.  I have already
spoken with the Ehcache devs.  I have reached out to the Infinispan team
but have not heard back


On Mon, Mar 5, 2018 at 10:46 AM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> 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
> >
>