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

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 >