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.s...@gmail.com> >wrote: > >> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <st...@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@lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
