Re: [hibernate-dev] 5.3 cache issues [Requires Steve]
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