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