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

On Wed, Jul 4, 2018 at 11:46 AM Emmanuel Bernard 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,

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

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

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

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

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

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

On Tue, Jul 3, 2018 at 5:11 AM Yoann Rodiere 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

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

> > 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 >

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

Then not sure why you ask if you already plan on your answer ;) On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet wrote: > On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote: > >> 1) That was specifically requested >> > > Sure. And we also have users who are unhappy with the new setup. > > This

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

On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole 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

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

Yes, what you describe is exactly the hybrid approach I suggested. On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea 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

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

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

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

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

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

Hi Steve, Glad to have you back! Hope yo got some rest. On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole 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

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

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

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

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/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing (The

Re: [hibernate-dev] 5.3 - hibernate-ehcache

+1. From my point of view this makes sense. I’ll need to confer with higher-ups about what we would then do regarding our copy of the Ehcache 2.x provider and whether we want to port it across to the new SPI. That should in principle be a separate discussion, but I’m a little too heads-down

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On Thu, Mar 15, 2018 at 9:30 AM Radim Vansa wrote: > Before Infinispan provides native implementation to 5.3/6.0 SPIs, JCache > is a good way to bridge the gap. So if you're setting up a matrix > testing, adding Infinispan JCache provider would give us some confidence > that

Re: [hibernate-dev] 5.3 - hibernate-ehcache

I'd have to look at the tests :) On Thu, Mar 15, 2018 at 9:46 AM Sanne Grinovero wrote: > On 15 March 2018 at 13:58, Steve Ebersole wrote: > > On Thu, Mar 15, 2018 at 8:47 AM Sanne Grinovero > wrote: > >> > >> > >> BTW what about

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On 15 March 2018 at 13:58, Steve Ebersole wrote: > On Thu, Mar 15, 2018 at 8:47 AM Sanne Grinovero wrote: >> >> >> BTW what about all of Alex's sophisticated integration tests? I assume >> they are more thorough in the older Ehcache module than in the

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On 03/15/2018 02:56 PM, Steve Ebersole wrote: > Inline > > On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero wrote: > >> On 15 March 2018 at 13:04, Steve Ebersole wrote: >>> Given the changes to the second-level cache SPI, I wonder if we want to >>>

Re: [hibernate-dev] 5.3 - hibernate-ehcache

Inline On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero wrote: > On 15 March 2018 at 13:04, Steve Ebersole wrote: > > Given the changes to the second-level cache SPI, I wonder if we want to > > take that as an opportunity to consider dropping the

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On 15 March 2018 at 13:44, Sanne Grinovero wrote: > On 15 March 2018 at 13:04, Steve Ebersole wrote: >> Given the changes to the second-level cache SPI, I wonder if we want to >> take that as an opportunity to consider dropping the `hibernate-ehcache` >>

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On 15 March 2018 at 13:04, Steve Ebersole wrote: > Given the changes to the second-level cache SPI, I wonder if we want to > take that as an opportunity to consider dropping the `hibernate-ehcache` > module? > > There are a few reasons I am considering this... > >1. We

[hibernate-dev] 5.3 - hibernate-ehcache

Given the changes to the second-level cache SPI, I wonder if we want to take that as an opportunity to consider dropping the `hibernate-ehcache` module? There are a few reasons I am considering this... 1. We have the JCache integration in place and users can use Ehcache via that support

Re: [hibernate-dev] 5.3 finalization plan

My preference is for the providers to handle that, yes. I have already spoken with the Ehcache devs. I have reached out to the Infinispan team but have not heard back On Mon, Mar 5, 2018 at 10:46 AM Scott Marlow wrote: > > > On 03/01/2018 02:37 PM, Steve Ebersole wrote: >

Re: [hibernate-dev] 5.3 finalization plan

On 03/01/2018 02:37 PM, Steve Ebersole wrote: > In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified > discussion about the remaining currently unresolved discussions and what > exactly we are going to do for 5.3 mainly in regards to compatibility with > an eye to 6.0 > > > >

Re: [hibernate-dev] 5.3 finalization plan

I have all of the caching and statistics changes done, however there are currently a few test failures because of the region-name issue. If I don't hear replies by Monday, I'll just pick a solution for that. Aka, speak now or forever hold your peace :) On Thu, Mar 1, 2018 at 1:37 PM Steve

[hibernate-dev] 5.3 finalization plan

In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified discussion about the remaining currently unresolved discussions and what exactly we are going to do for 5.3 mainly in regards to compatibility with an eye to 6.0 Cache region-name as exposed in API/SPI This one is a "sneaky"

Re: [hibernate-dev] 5.3?

Because we likely have more breaking changed planned in 6.0, I don't think your renaming plan would add a lot. Better focus on 6. > On 18 août 2016, at 14:42, Scott Marlow wrote: > > >> On 08/17/2016 03:54 PM, Steve Ebersole wrote: >> For whatever reason discussion about

Re: [hibernate-dev] 5.3?

Quite some time I would think. I plan to have a first Alpha after we finish up this first round of the type system redesign. I'd love to see that by Sept, Oct. I'll have a better idea then. On Fri, Aug 19, 2016 at 1:07 AM Gunnar Morling wrote: > Hi, What's your time

Re: [hibernate-dev] 5.3?

On 08/18/2016 03:52 PM, Steve Ebersole wrote: > I'm not following the 5.2 -> 6.0 piece. You mean because we merged the > JPA contracts into our version of those contracts directly? Yes, as part of that change, I believe that we also made some changes to which exceptions are being thrown,

Re: [hibernate-dev] 5.3?

Hi, What's your time plan for releasing 6.0? In other words, how much longer would people have to way for the Money support if it wouldn't be released as part of another 5.x release? 2016-08-18 21:54 GMT+02:00 Steve Ebersole : > Especially because it is hitting directly an

Re: [hibernate-dev] 5.3?

Especially because it is hitting directly an area (type system) we are majorly overhauling. Adding more stuff in 5.x that we need to convert later to the new contracts is not ideal. Just thought I'd throw it out there though to gauge interest. On Thu, Aug 18, 2016 at 8:43 AM andrea boriero

Re: [hibernate-dev] 5.3?

I'm not following the 5.2 -> 6.0 piece. You mean because we merged the JPA contracts into our version of those contracts directly? That led to very few *real* migration problems. The only ones I know of are the once where we had to rename the Hibernate version of a method because JPA happened

Re: [hibernate-dev] 5.3?

I would prefer to postpone JavaMoney/Moneta integration to 6.0. In case this is not possible I agree with including also the CDI work. On 17 Aug 2016 21:56, "Steve Ebersole" wrote: > For whatever reason discussion about JavaMoney/Moneta support has heated up > again the

Re: [hibernate-dev] 5.3?

On 08/17/2016 03:54 PM, Steve Ebersole wrote: > For whatever reason discussion about JavaMoney/Moneta support has heated up > again the past few days. Is this important enough to warrant a 5.3 release? My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based on the current ORM

[hibernate-dev] 5.3?

For whatever reason discussion about JavaMoney/Moneta support has heated up again the past few days. Is this important enough to warrant a 5.3 release? If we are going to cut a 5.3 I'd also suggest we include the recent work I did in regards to CDI support as well[1]. [1]