Re: [hibernate-dev] HHH-10418 and Infinispan

I see that HHH-11356 is scheduled for 6.0.0.Beta1. Any chance it could be fixed in 5.3? On Thu, Nov 16, 2017 at 10:23 PM, Gail Badner wrote: > Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in > master. [1] > > Maybe it's just the CCE that got fixed.

Re: [hibernate-dev] HHH-10418 and Infinispan

Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in master. [1] Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 to clarify that entities and collections still cannot be stored in the same region in 5.2. [1]

Re: [hibernate-dev] HHH-10418 and Infinispan

No that is currently broken. See https://hibernate.atlassian.net/browse/HHH-11356 This won't be fixed in 5.x as fixing it required significant changes to the caching SPIs to resolve. On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: > Steve/Radim, > > Is it OK if an

[hibernate-dev] HHH-10418 and Infinispan

Steve/Radim, Is it OK if an entity and collection region have the same name, they will use the same AdvancedCache? I realize that the key will be different (as long as hibernate.cache.keys_factory != simple). I'm assuming they use the same access strategies, etc. I know there would be problems

Re: [hibernate-dev] JPA Compliance

When I said multiple modes, I was thinking of defining all these situations In some interface which declares methods like: boolean throwsExceptionWhenClosingAClosedEMF() The interface can have two implementations for Strict JPA and Native mode. However, the setting could take the FQN of the

Re: [hibernate-dev] JPA Compliance

There is already a similar setting, although specific to query language: `hibernate.query.jpaql_strict_compliance` - so there is precedence for such a solution. I'm not sure about the "with multiple modes" aspect though. What are these other enumerated mode values? On Thu, Nov 16, 2017 at 2:15

Re: [hibernate-dev] JPA Compliance

Where the JPA way is questionable, let's add one configuration: hibernate.jpa.compliance with multiple modes: - strict: we do whatever the JPA standard says we should do, like throwing an exception when trying to close the EMF twice - native: we bend the rule where we don't agree with the

Re: [hibernate-dev] JPA Compliance

It was added deprecated. Meaning I added it knowing it would go away and I wanted to avoid users using it. BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. Its specifically the "where the JPA way is

Re: [hibernate-dev] JPA Compliance

Hi Steve, I think that for 5.2 was ok to have the isJpaBootstrap method to avoid breaking compatibility for the native bootstrap. For 6.0, maybe it's easier if we just align to the JPA spec where it makes sense, and only provide a separation where the JPA way is questionable. I noticed that the

[hibernate-dev] JPA Compliance

Part of 5.2 was merging the JPA contracts into the corresponding Hibernate ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of EntityManagerFactory - instead, SessionFactory now extends EntityManagerFactory. This caused a few problems that we handled as they came up. In working