[hibernate-dev] 5.3 cache issues [Requires Steve]

[Guillaume Smet]

On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve at hibernate.org> wrote:

> 1) That was specifically requested
>

Sure. And we also have users who are unhappy with the new setup.

This was also changed for the legacy Ehcache 2 provider which is a pity
IMHO.


> 2) This is easily handled by the providers, if they wish.  They would
> simply map any undefined regions/caches to a pre-defined one (probably
> after warning the user).  Keep in mind that region != cache.  A provider
> might map multiple region names to a single cache.  That was always the
> case, but every provider mapped region <-> cache as 1-1 - the new API makes
> this much more clear.
>
> Personally I think that not allowing on-the-fly creation is a good idea,
> though maybe it can be made configurable.
>

Well, the fact is that it can be a perfectly valid setup if you have
defined a default template for your caches. Typically, as explained here:
https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080
or in the Ehcache documentation for JCache.

If I have 500 entities, using the default default JCache provider, I have
to define the configuration for these 500 caches (+ the ones for the
collections). Whereas I could use a template for most of them. Note that
this is not a rhetorical position: we did that for all our applications
with Yoann at our previous job: sane default cache + fine tuning for
specific entities.

My personal opinion is that we should have a warning explaining the
situation and the frameworks could choose to throw an error if they see fit
but I don't think the default setup should be to throw an error.

Apart from the valid default template case, not being to start your
application until all your caches are configured doesn't seem very helpful
when you are developing your application. You don't start your development
by fine tuning all your caches: it's something you usually do before
pushing your app to production and then adjust with the feedback you have
from the field.

And if you want to be sure, when you push it to production, you can use the
new configuration property Yoann introduced in his PR to make it fail.

-- 
Guillaume