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

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(a)hibernate.org&gt; 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(a)gmail.com&gt; > >wrote: > > > >> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)hibernate.org&gt; > 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&... > >> 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 > &gt;hibernate-dev(a)lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/hibernate-dev >