Hi all, So following our off-list discussions , I wanted to share a document we wrote with Yoann with some details about the usability/compatibility of the new cache implementation in 5.3: https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX... (The document should be public and everyone should be able to comment) We tried to be as detailed as possible. What we need to decide is in bold/red as Actions. The idea is to act on it for 5.3.2 so before Thursday. The PR for the first issue is mostly ready but will require some tuning depending on our decisions, we still need to work on the second one depending on the outcome. Everyone interested/concerned, please step in so that we can reach a consensus quickly and merge what is appropriate. Thanks! -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi Steve, Glad to have you back! Hope yo got some rest. On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Overall what I would suggest is a hybrid approach where we move to a > "short name" solution much like we have for most other config values. So, > e.g., the name of the default query result region would be > `default-query-result-region`. We could then have the providers understand > that "magic value" and have them look for configs under either names they > wish (temporarily which Emmanuel suggested, if that's what we want) - we'd > change our OOTB providers to look for all three names. > Sounds like something we could do, given we implement the compatibility layer. We would need a new release of the Infinispan region factory to provide the compatibility layer there. Any comment on the first issue (the new requirement to declare all the caches)? -- Guillaume

The short name approach sounds goid and would accommodate any future cache region implementation changes. For 5.3, I'd say we allow the old named to be resolved to the new ones, like symbolic links. This will allow users to migrate to 5.3 without changing existing ehcache.xml configs. We could write a log WARN for 5.3 and stop supporting old region names in 6.x. Vlad On Mon, 2 Jul 2018, 23:00 Steve Ebersole, <steve(a)hibernate.org&gt; wrote: > Changing the name of the default query results cache I can see being a > problem in retrospect. That is something the user might want to > configure. > > I am much less convinced about the update-timestamps cache. I guess it > would depend on what they are configuring. > > Overall what I would suggest is a hybrid approach where we move to a > "short > name" solution much like we have for most other config values. So, e.g., > the name of the default query result region would be > `default-query-result-region`. We could then have the providers > understand > that "magic value" and have them look for configs under either names they > wish (temporarily which Emmanuel suggested, if that's what we want) - we'd > change our OOTB providers to look for all three names. > > On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; > wrote: > > > Hi all, > > > > So following our off-list discussions , I wanted to share a document we > > wrote with Yoann with some details about the usability/compatibility of > the > > new cache implementation in 5.3: > > > > > https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX... > > > > (The document should be public and everyone should be able to comment) > > > > We tried to be as detailed as possible. What we need to decide is in > > bold/red as Actions. > > > > The idea is to act on it for 5.3.2 so before Thursday. The PR for the > first > > issue is mostly ready but will require some tuning depending on our > > decisions, we still need to work on the second one depending on the > > outcome. > > > > Everyone interested/concerned, please step in so that we can reach a > > consensus quickly and merge what is appropriate. > > > > Thanks! > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

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

Then not sure why you ask if you already plan on your answer ;)

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 hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 >