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

[Emmanuel Bernard]

Let's keep this consistent and use the create-warn for all cases.
I understand why the user raised the original JIRA, and yes on paper,
failing is the safer prod friendly option.
But we must cater to the ease of development too. The development
workflow and experience is an important aspect that we must take care
of.

Having the create-warn by default and allowing the user to move to
create or fail is a good compromise. Vlad, in the documentation, we can
have a get ready for production section that mention this problem and
many others :)

I like the idea of Guillaume to try and capture all failing cache
creations and return them as a single error. It's not a blocker though
and if that cannot make it in our 5.3 sprint, that is acceptable.

Emmanuel

On Wed 18-07-04 10:32, Guillaume Smet wrote:
>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
>>