10:04 a.m.
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
10:28 a.m.
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>
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
11:18 a.m.
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> 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
2:14 p.m.
1) That was specifically requested
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.
On Mon, Jul 2, 2018 at 11:18 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
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> 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
5:47 p.m.
On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)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&...
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
6:03 p.m.
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>
wrote:
On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole
<steve(a)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&...
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
1:33 a.m.
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.
Just to clarify: this would require cache implementors to provide their own
region factory, and in that case we all agree they can do whatever they
want, which is nice.
The problem is more with the built-in Ehcache and JCache region factories.
Our built-in region factories call getCache(String), and if it returns
null, they throw an exception. So the cache implementors do not have an
easy way to auto-create a cache using some internal, default configuration:
they would have to do that in the getCache(String) method, and it's
arguably not something you want to do in a method with such a name,
especially considering it's exposed to other clients than just Hibernate
ORM. And I'm not sure the JCache specification even allows that.
Ideally we'd like Ehcache/JCache to expose some getOrCreate(String) method,
and decide for themselves whether to throw an exception or not, but well...
they don't. Which explains the suggestion to handle the "default" logic on
our end.
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On Tue, 3 Jul 2018 at 01:04, Steve Ebersole <steve(a)hibernate.org> 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>
wrote:
> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)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&...
> 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
8:11 a.m.
On Tue, Jul 3, 2018 at 5:11 AM Yoann Rodiere <yoann(a)hibernate.org> wrote:
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.
Just to clarify: this would require cache implementors to provide their
own region factory, and in that case we all agree they can do whatever they
want, which is nice.
The problem is more with the built-in Ehcache and JCache region factories.
Our built-in region factories call getCache(String), and if it returns
null, they throw an exception. So the cache implementors do not have an
easy way to auto-create a cache using some internal, default configuration:
they would have to do that in the getCache(String) method, and it's
arguably not something you want to do in a method with such a name,
especially considering it's exposed to other clients than just Hibernate
ORM. And I'm not sure the JCache specification even allows that.
Ideally we'd like Ehcache/JCache to expose some getOrCreate(String)
method, and decide for themselves whether to throw an exception or not, but
well... they don't. Which explains the suggestion to handle the "default"
logic on our end.
Not sure exactly what you expect this to return - that's the problem. It
would need to return a `net.sf.ehcache.Cache` or a `javax.cache.Cache` or a
...
So I think you need to split this into a discussion about Ehcache and one
about JCache.
For Ehcache... whatever. As I keep saying, that provider is based on
Ehcache 2 which the Ehcache team hasn't supported for years now. People
really should not be using that one. If you want to revert that one,
that's fine
For JCache, as I have already said, I am fine with adding a setting here to
allow on-the-fly creations. On-the-fly creations are a terrible idea, but
people can chose that option if they wish.
Just make sure that any logging here (especially the "we are creating an
on-the-fly Cache for you") happens through
`org.hibernate.cache.spi.SecondLevelCacheLogger`
3:13 a.m.
On Tue, Jul 3, 2018 at 1:03 AM Steve Ebersole <steve(a)hibernate.org> wrote:
Then not sure why you ask if you already plan on your answer ;)
Well, obviously, I think there's something wrong, otherwise I wouldn't have
raised the issue in the first place and waste everyone's time :). But
you're the project lead and you did the work on this so, yes, I prefer
asking if you veto it or not.
What also bugs me a bit is that with the fail route, the user only has one
error at a time: so basically, you have to start your app, fix the first
error, restart your app, fix the following one. The warning route is far
more straightforward as you have all the issues at once.
Having a configuration knob and allowing framework vendors to choose the
strict rule if they want seems acceptable to me, that's why I'm defending
this position.
If you don't have a strong opinion about it, I think it's the best
compromise we can make to take into account all the feedback we had about
this and have the best usability so I'm leaning towards applying Yoann's PR.
--
Guillaume
8:14 a.m.
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>
wrote:
> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)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&...
> 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
3:32 a.m.
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>
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>
>wrote:
>
>> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)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&...
>> 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
4:46 a.m.
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(a)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(a)gmail.com>
> >wrote:
> >
> >> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve(a)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&...
> >> 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
>
6 a.m.
On Wed, Jul 4, 2018 at 11:46 AM Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
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 :)
OK, done.
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.
So in the default create-warn case, you obviously have listed all the
caches that are not defined.
It might be nice to do the same thing for the fail case but that is for
another day.
--
Guillaume
3:51 p.m.
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> 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>
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
4:35 p.m.
Yes, what you describe is exactly the hybrid approach I suggested.
On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
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> 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>
> 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
>
2387
days inactive
2389
days old
14 comments
5 participants
participants (5)
-
Emmanuel Bernard -
Guillaume Smet -
Steve Ebersole -
Vlad Mihalcea -
Yoann Rodiere