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

[Guillaume Smet]

Hi,

Current status:
- short names and compatibility layer on the ORM side: merged
- Radim will get the Infinispan region factory up to speed (Thanks!)
- we merged the configuration knobs to allow the automatic creation of
caches:
. default for Ehcache: create-warn: cache will be automatically created but
there will be warnings
. default for JCache: fail: failure at bootstrap if there is a missing cache

I haven't had any answer to my case against having fail as the default for
JCache so I suppose it's how it is.

-- 
Guillaume

On Tue, Jul 3, 2018 at 3:15 PM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I think they are afraid of you Steve :D
>
> When asking, we could make it clear where we stand:
> - I feel unsure and need someone else to back me up, ideally the project
>   lead
> - I think I'm right but let's see if Steve or other knowledgable person
>   comes with a strong argument against
> - I don't want to make the decision, whatever someone else decides
>
> At least it gives the right frame of thinking to the person answering.
>
> Emmanuel
>
> On Mon 18-07-02 18:03, Steve Ebersole wrote:
> >Then not sure why you ask if you already plan on your answer ;)
> >
> >On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet <guillaume.smet at gmail.com>
> >wrote:
> >
> >> 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
> >>
> >_______________________________________________
> >hibernate-dev mailing list
> >hibernate-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>