Re: [hibernate-dev] 5.3 finalization plan

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >