Yes, what you describe is exactly the hybrid approach I suggested.
On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
The short name approach sounds goid and would accommodate any future
cache
region implementation changes.
For 5.3, I'd say we allow the old named to be resolved to the new ones,
like symbolic links.
This will allow users to migrate to 5.3 without changing existing
ehcache.xml configs.
We could write a log WARN for 5.3 and stop supporting old region names in
6.x.
Vlad
On Mon, 2 Jul 2018, 23:00 Steve Ebersole, <steve(a)hibernate.org> wrote:
> Changing the name of the default query results cache I can see being a
> problem in retrospect. That is something the user might want to
> configure.
>
> I am much less convinced about the update-timestamps cache. I guess it
> would depend on what they are configuring.
>
> Overall what I would suggest is a hybrid approach where we move to a
> "short
> name" solution much like we have for most other config values. So, e.g.,
> the name of the default query result region would be
> `default-query-result-region`. We could then have the providers
> understand
> that "magic value" and have them look for configs under either names they
> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
> change our OOTB providers to look for all three names.
>
> On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
>
> > Hi all,
> >
> > So following our off-list discussions , I wanted to share a document we
> > wrote with Yoann with some details about the usability/compatibility of
> the
> > new cache implementation in 5.3:
> >
> >
>
https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX...
> >
> > (The document should be public and everyone should be able to comment)
> >
> > We tried to be as detailed as possible. What we need to decide is in
> > bold/red as Actions.
> >
> > The idea is to act on it for 5.3.2 so before Thursday. The PR for the
> first
> > issue is mostly ready but will require some tuning depending on our
> > decisions, we still need to work on the second one depending on the
> > outcome.
> >
> > Everyone interested/concerned, please step in so that we can reach a
> > consensus quickly and merge what is appropriate.
> >
> > Thanks!
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>