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 isJpaBootstrap method is deprecated. Was it intended to be removed in 6.0? Vlad On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole wrote: > 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 on > the JPA 2.2 compatibility testing, I see that there are a few more still > that we need to resolve. Mostly they relate to JPA expecting exceptions in > certain cases where Hibernate has historically been lenient. E.g., JPA > says that calling EntityManagerFactory#close on an EMF that is already > closed should result in an exception. Historically, calling > SessionFactory#close on a SF that is already closed is simply ignored. > Philosophical debates aside[1], we need to decide how we want to handle > this situation such that we can throw the JPA-expected exceptions when > needed. Do we simply change SF#close to match the JPA expectation? Or do > we somehow > make SF#close aware of JPA versus "native" use? This latter option was the > intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly > continue to use that as the basis of the solution here for other cases. > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if > the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, > that flag is set to true. It's an ok solution, but it does have some > limitations - mainly, there was previously a distinction between SF#close > being called versus EMF#close being called (they were different classes, so > they could react differently). Therefore, regardless of bootstrap > mechanism, if the user unwrapped the EMF to a SF, they would always get the > legacy SF behavior. > > So long story short, so we want to consider an alternative approach to > deciding what to do in "some"[2] of these cases? Again, we clearly need > these to throw the spec-mandated exceptions in certain "strict compliance" > situations. The question really is how to do that. Should we: > >1. just completely change the behavior to align with the spec? >2. change the behavior to match the spec *conditionally*, where that >condition could be: > 1. `#isJpaBootstrap` > 2. some setting > 3. some extension contract > 4. something else? > > Thoughts? > > > [1] It's not relevant e.g. that I think JPA is wrong here. We need to > comply with the spec, at least in certain cases ;) > > [2] I say "some" here, because I think the spec is correct in some cases - > for example, I think its clearly correct that a closed EMF throws an > exception when `#createEntityManager` is called. Personally I think its > questionable whether closing an already closed EMF should be an exception. > ___ > 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
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 questionable" aspect I am asking about. Like to me, it really never makes sense to throw an exception when I close something that is already closed. So how do we handle cases like this? On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea wrote: > 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 isJpaBootstrap method is deprecated. Was it intended > to be removed in 6.0? > > Vlad > > On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > wrote: > >> 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 on >> the JPA 2.2 compatibility testing, I see that there are a few more still >> that we need to resolve. Mostly they relate to JPA expecting exceptions >> in >> certain cases where Hibernate has historically been lenient. E.g., JPA >> says that calling EntityManagerFactory#close on an EMF that is already >> closed should result in an exception. Historically, calling >> SessionFactory#close on a SF that is already closed is simply ignored. >> Philosophical debates aside[1], we need to decide how we want to handle >> this situation such that we can throw the JPA-expected exceptions when >> needed. Do we simply change SF#close to match the JPA expectation? Or do >> we somehow >> make SF#close aware of JPA versus "native" use? This latter option was >> the >> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >> continue to use that as the basis of the solution here for other cases. >> >> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >> if >> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >> that flag is set to true. It's an ok solution, but it does have some >> limitations - mainly, there was previously a distinction between SF#close >> being called versus EMF#close being called (they were different classes, >> so >> they could react differently). Therefore, regardless of bootstrap >> mechanism, if the user unwrapped the EMF to a SF, they would always get >> the >> legacy SF behavior. >> >> So long story short, so we want to consider an alternative approach to >> deciding what to do in "some"[2] of these cases? Again, we clearly need >> these to throw the spec-mandated exceptions in certain "strict compliance" >> situations. The question really is how to do that. Should we: >> >>1. just completely change the behavior to align with the spec? >>2. change the behavior to match the spec *conditionally*, where that >>condition could be: >> 1. `#isJpaBootstrap` >> 2. some setting >> 3. some extension contract >> 4. something else? > > >> >> Thoughts? >> >> >> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >> comply with the spec, at least in certain cases ;) >> >> [2] I say "some" here, because I think the spec is correct in some cases - >> for example, I think its clearly correct that a closed EMF throws an >> exception when `#createEntityManager` is called. Personally I think its >> questionable whether closing an already closed EMF should be an exception. >> > ___ >> 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
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 standard Maybe we should expose all those cases and group them in some interface to allow the user to customize the level of compliance they need. Vlad On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole wrote: > 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 questionable" aspect I am > asking about. Like to me, it really never makes sense to throw an > exception when I close something that is already closed. So how do we > handle cases like this? > > > On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea > wrote: > >> 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 isJpaBootstrap method is deprecated. Was it intended >> to be removed in 6.0? >> >> Vlad >> >> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >> wrote: >> >>> 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 >>> on >>> the JPA 2.2 compatibility testing, I see that there are a few more still >>> that we need to resolve. Mostly they relate to JPA expecting exceptions >>> in >>> certain cases where Hibernate has historically been lenient. E.g., JPA >>> says that calling EntityManagerFactory#close on an EMF that is already >>> closed should result in an exception. Historically, calling >>> SessionFactory#close on a SF that is already closed is simply ignored. >>> Philosophical debates aside[1], we need to decide how we want to handle >>> this situation such that we can throw the JPA-expected exceptions when >>> needed. Do we simply change SF#close to match the JPA expectation? Or >>> do >>> we somehow >>> make SF#close aware of JPA versus "native" use? This latter option was >>> the >>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >>> continue to use that as the basis of the solution here for other cases. >>> >>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >>> if >>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >>> that flag is set to true. It's an ok solution, but it does have some >>> limitations - mainly, there was previously a distinction between SF#close >>> being called versus EMF#close being called (they were different classes, >>> so >>> they could react differently). Therefore, regardless of bootstrap >>> mechanism, if the user unwrapped the EMF to a SF, they would always get >>> the >>> legacy SF behavior. >>> >>> So long story short, so we want to consider an alternative approach to >>> deciding what to do in "some"[2] of these cases? Again, we clearly need >>> these to throw the spec-mandated exceptions in certain "strict >>> compliance" >>> situations. The question really is how to do that. Should we: >>> >>>1. just completely change the behavior to align with the spec? >>>2. change the behavior to match the spec *conditionally*, where that >>>condition could be: >>> 1. `#isJpaBootstrap` >>> 2. some setting >>> 3. some extension contract >>> 4. something else? >> >> >>> >>> Thoughts? >>> >>> >>> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >>> comply with the spec, at least in certain cases ;) >>> >>> [2] I say "some" here, because I think the spec is correct in some cases >>> - >>> for example, I think its clearly correct that a closed EMF throws an >>> exception when `#createEntityManager` is called. Personally I think its >>> questionable whether closing an already closed EMF should be an >>> exception. >>> >> ___ >>> 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
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 PM Vlad Mihalcea wrote: > 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 standard > > Maybe we should expose all those cases and group them in some interface to > allow the user to customize the level of compliance they need. > > Vlad > > On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole > wrote: > >> 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 questionable" aspect I am >> asking about. Like to me, it really never makes sense to throw an >> exception when I close something that is already closed. So how do we >> handle cases like this? >> >> >> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >> wrote: >> >>> 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 isJpaBootstrap method is deprecated. Was it intended >>> to be removed in 6.0? >>> >>> Vlad >>> >>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >>> wrote: >>> 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 on the JPA 2.2 compatibility testing, I see that there are a few more still that we need to resolve. Mostly they relate to JPA expecting exceptions in certain cases where Hibernate has historically been lenient. E.g., JPA says that calling EntityManagerFactory#close on an EMF that is already closed should result in an exception. Historically, calling SessionFactory#close on a SF that is already closed is simply ignored. Philosophical debates aside[1], we need to decide how we want to handle this situation such that we can throw the JPA-expected exceptions when needed. Do we simply change SF#close to match the JPA expectation? Or do we somehow make SF#close aware of JPA versus "native" use? This latter option was the intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly continue to use that as the basis of the solution here for other cases. This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, that flag is set to true. It's an ok solution, but it does have some limitations - mainly, there was previously a distinction between SF#close being called versus EMF#close being called (they were different classes, so they could react differently). Therefore, regardless of bootstrap mechanism, if the user unwrapped the EMF to a SF, they would always get the legacy SF behavior. So long story short, so we want to consider an alternative approach to deciding what to do in "some"[2] of these cases? Again, we clearly need these to throw the spec-mandated exceptions in certain "strict compliance" situations. The question really is how to do that. Should we: 1. just completely change the behavior to align with the spec? 2. change the behavior to match the spec *conditionally*, where that condition could be: 1. `#isJpaBootstrap` 2. some setting 3. some extension contract 4. something else? >>> >>> Thoughts? [1] It's not relevant e.g. that I think JPA is wrong here. We need to comply with the spec, at least in certain cases ;) [2] I say "some" here, because I think the spec is correct in some cases - for example, I think its clearly correct that a closed EMF throws an exception when `#createEntityManager` is called. Personally I think its questionable whether closing an already closed EMF should be an exception. >>> ___ hibernat
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 interface implementation, so a user can define those compatibility methods according to their needs. E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; - don't throw exception when closing the ENG twice - use the native Hibernate FlushMode.AUTO instead of the JPA one. Vlad On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > 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 PM Vlad Mihalcea > wrote: > >> 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 standard >> >> Maybe we should expose all those cases and group them in some interface >> to allow the user to customize the level of compliance they need. >> >> Vlad >> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> wrote: >> >>> 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 questionable" aspect I am >>> asking about. Like to me, it really never makes sense to throw an >>> exception when I close something that is already closed. So how do we >>> handle cases like this? >>> >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >>> wrote: >>> 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 isJpaBootstrap method is deprecated. Was it intended to be removed in 6.0? Vlad On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole wrote: > 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 on > the JPA 2.2 compatibility testing, I see that there are a few more > still > that we need to resolve. Mostly they relate to JPA expecting > exceptions in > certain cases where Hibernate has historically been lenient. E.g., JPA > says that calling EntityManagerFactory#close on an EMF that is already > closed should result in an exception. Historically, calling > SessionFactory#close on a SF that is already closed is simply ignored. > Philosophical debates aside[1], we need to decide how we want to handle > this situation such that we can throw the JPA-expected exceptions when > needed. Do we simply change SF#close to match the JPA expectation? > Or do > we somehow > make SF#close aware of JPA versus "native" use? This latter option > was the > intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly > continue to use that as the basis of the solution here for other cases. > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. > So if > the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, > that flag is set to true. It's an ok solution, but it does have some > limitations - mainly, there was previously a distinction between > SF#close > being called versus EMF#close being called (they were different > classes, so > they could react differently). Therefore, regardless of bootstrap > mechanism, if the user unwrapped the EMF to a SF, they would always > get the > legacy SF behavior. > > So long story short, so we want to consider an alternative approach to > deciding what to do in "some"[2] of these cases? Again, we clearly > need > these to throw the spec-mandated exceptions in certain "strict > compliance" > situations. The question really is how to do that. Should we: > >1. just completely change the behavior to align with the spec? >2. change the behavior
Re: [hibernate-dev] JPA Compliance
I think for 5.3 it's still fine to rely on isJpaBootstrap may be documenting that a SF obtained from unwrapping an EMF will conform to the JPA spec in term of exceptions. On 16 November 2017 at 21:09, Vlad Mihalcea wrote: > 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 interface implementation, so > a user can define those compatibility methods according to their needs. > > E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; > > - don't throw exception when closing the ENG twice > - use the native Hibernate FlushMode.AUTO instead of the JPA one. > > Vlad > > On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > > > 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 PM Vlad Mihalcea > > wrote: > > > >> 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 standard > >> > >> Maybe we should expose all those cases and group them in some interface > >> to allow the user to customize the level of compliance they need. > >> > >> Vlad > >> > >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole > >> wrote: > >> > >>> 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 questionable" aspect I am > >>> asking about. Like to me, it really never makes sense to throw an > >>> exception when I close something that is already closed. So how do we > >>> handle cases like this? > >>> > >>> > >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea > > >>> wrote: > >>> > 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 isJpaBootstrap method is deprecated. Was it > intended to be removed in 6.0? > > Vlad > > On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > wrote: > > > 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 on > > the JPA 2.2 compatibility testing, I see that there are a few more > > still > > that we need to resolve. Mostly they relate to JPA expecting > > exceptions in > > certain cases where Hibernate has historically been lenient. E.g., > JPA > > says that calling EntityManagerFactory#close on an EMF that is > already > > closed should result in an exception. Historically, calling > > SessionFactory#close on a SF that is already closed is simply > ignored. > > Philosophical debates aside[1], we need to decide how we want to > handle > > this situation such that we can throw the JPA-expected exceptions > when > > needed. Do we simply change SF#close to match the JPA expectation? > > Or do > > we somehow > > make SF#close aware of JPA versus "native" use? This latter option > > was the > > intent of `SessionFactoryOptions#isJpaBootstrap` and we can > certainly > > continue to use that as the basis of the solution here for other > cases. > > > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. > > So if > > the EMF is created in either of the 2 JPA-defined bootstrap > mechanisms, > > that flag is set to true. It's an ok solution, but it does have some > > limitations - mainly, there was previously a distinction between > > SF#close > > being called versus EMF#close being called (they were different > > classes, so > > they could react differently). Therefore, regardless of bootstrap > > mechanism, if the user unwrapped the EMF to a SF, they would always > > get the
Re: [hibernate-dev] JPA Compliance
I should have said: Another thing I was discussing with Andrea in chat is possibly making these multi-valued, or having multiple values for this. I can't imagine the FQN case is really all that appealing to a user. I'm fairly certain a user would rather simply say "yeah, treat transactions according the JPA spec" as opposed to "here is a class I will provide that will tell will treat transactions according to the JPA spec". ***Or have multiple settings following how I started with `hibernate.query.jpaql_strict_compliance`*** On Fri, Nov 24, 2017 at 11:39 AM Steve Ebersole wrote: > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > > Another thing I was discussing with Andrea in chat is possibly making > these multi-valued, or having multiple values for this. I can't imagine > the FQN case is really all that appealing to a user. I'm fairly certain a > user would rather simply say "yeah, treat transactions according the JPA > spec" as opposed to "here is a class I will provide that will tell will > treat transactions according to the JPA spec". > > We have started to identify some cases where we deviate from the spec[1], > such as: > * Strict query compliance. As I mentioned earlier we do have such a > setting already for this in particular > * List versus Bag determination from mappings. > * Closed EMF (SF) handling > * EntityTransaction status checking - JPA says we should throw exceptions > whereas we just ignore the call. > > We need to decide also which of these we want to just change outright > versus controlling via a setting. > > * Setting > * Setting, or introduce a new @Bag annotation - the annotation option is > actually pretty appealing since often times the bag behavior is so > unexpected from users... > * I think we should just change the behavior of calling EMF#close on a > closed EMF. Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` > check. In fact I think we should change all of these to match the JPA > expectations such that it is an error to call any of the following: #close, > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty > reasonable. And in fact I think we used to handle this all properly from > the EMF side. I think we just lost that behavior when we changed to have > our contracts extend the JPA ones since we kept the legacy Hibernate > behavior in SessionFactory. > * This one I am very undecided. I can see very valid arguments for each. > > [1] we really ought to start keeping a list of these. I have started > adding them to the migration guide. Just as a list of things we need to > support configuring or switch to the JPA "way". > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > wrote: > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >> documenting that a SF obtained from unwrapping an EMF will conform to the >> JPA spec in term of exceptions. >> >> On 16 November 2017 at 21:09, Vlad Mihalcea >> wrote: >> >>> 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 interface implementation, >>> so >>> a user can define those compatibility methods according to their needs. >>> >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >>> >>> - don't throw exception when closing the ENG twice >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>> >>> Vlad >>> >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>> >>> > 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 PM Vlad Mihalcea >> > >>> > wrote: >>> > >>> >> 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 standard >>> >> >>> >> Maybe we should expose all those cases and group them in some >>> interface >>> >> to allow the user to customize the level of compliance they need. >>> >> >>> >> Vlad >>> >> >>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> > >>> >> wrote: >>> >> >>> >>> It was added deprecated. Meaning I added it knowing it would go away >>> >>> and I wanted to avoid users using it. >>> >>> >>> >>> BTW
Re: [hibernate-dev] JPA Compliance
Andrea, SF is a EMF. Unwrapping simply returns the same instance. Another thing I was discussing with Andrea in chat is possibly making these multi-valued, or having multiple values for this. I can't imagine the FQN case is really all that appealing to a user. I'm fairly certain a user would rather simply say "yeah, treat transactions according the JPA spec" as opposed to "here is a class I will provide that will tell will treat transactions according to the JPA spec". We have started to identify some cases where we deviate from the spec[1], such as: * Strict query compliance. As I mentioned earlier we do have such a setting already for this in particular * List versus Bag determination from mappings. * Closed EMF (SF) handling * EntityTransaction status checking - JPA says we should throw exceptions whereas we just ignore the call. We need to decide also which of these we want to just change outright versus controlling via a setting. * Setting * Setting, or introduce a new @Bag annotation - the annotation option is actually pretty appealing since often times the bag behavior is so unexpected from users... * I think we should just change the behavior of calling EMF#close on a closed EMF. Any application that happens to be relying on us no-op'ing this call can easily change that to protect the call with an `#isOpen` check. In fact I think we should change all of these to match the JPA expectations such that it is an error to call any of the following: #close, #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty reasonable. And in fact I think we used to handle this all properly from the EMF side. I think we just lost that behavior when we changed to have our contracts extend the JPA ones since we kept the legacy Hibernate behavior in SessionFactory. * This one I am very undecided. I can see very valid arguments for each. [1] we really ought to start keeping a list of these. I have started adding them to the migration guide. Just as a list of things we need to support configuring or switch to the JPA "way". On Fri, Nov 17, 2017 at 11:06 AM andrea boriero wrote: > I think for 5.3 it's still fine to rely on isJpaBootstrap may be > documenting that a SF obtained from unwrapping an EMF will conform to the > JPA spec in term of exceptions. > > On 16 November 2017 at 21:09, Vlad Mihalcea > wrote: > >> 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 interface implementation, >> so >> a user can define those compatibility methods according to their needs. >> >> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >> >> - don't throw exception when closing the ENG twice >> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >> >> Vlad >> >> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >> >> > 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 PM Vlad Mihalcea >> > wrote: >> > >> >> 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 standard >> >> >> >> Maybe we should expose all those cases and group them in some interface >> >> to allow the user to customize the level of compliance they need. >> >> >> >> Vlad >> >> >> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> >> wrote: >> >> >> >>> 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 questionable" aspect I am >> >>> asking about. Like to me, it really never makes sense to throw an >> >>> exception when I close something that is already closed. So how do we >> >>> handle cases like this? >> >>> >> >>> >> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea < >> mihalcea.v...@gmail.com> >> >>> wrote: >> >>> >> 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
Re: [hibernate-dev] JPA Compliance
> I think we should just change the behavior of calling EMF#close on a closed EMF. > Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` check. Mentioning this just in case: the javadoc for the AutoCloseable interface recommends making implementations of #close idempotent (not throwing exceptions when called twice). Since Session extends AutoCloseable, and IIRC there was a ticket about making EntityManager also extend AutoCloseable, I thought this would be relevant. I personally think that such a behavior is nice as it makes resource management a little bit simpler, but in any case the interface does not mandate it: it's just a recommendation. So you sure can do what you want. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On 24 November 2017 at 18:42, Steve Ebersole wrote: > I should have said: > > Another thing I was discussing with Andrea in chat is possibly making these > multi-valued, or having multiple values for this. I can't imagine the FQN > case is really all that appealing to a user. I'm fairly certain a user > would rather simply say "yeah, treat transactions according the JPA spec" > as opposed to "here is a class I will provide that will tell will treat > transactions according to the JPA spec". ***Or have multiple settings > following how I started with `hibernate.query.jpaql_strict_compliance`*** > > On Fri, Nov 24, 2017 at 11:39 AM Steve Ebersole > wrote: > > > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > > > > Another thing I was discussing with Andrea in chat is possibly making > > these multi-valued, or having multiple values for this. I can't imagine > > the FQN case is really all that appealing to a user. I'm fairly certain > a > > user would rather simply say "yeah, treat transactions according the JPA > > spec" as opposed to "here is a class I will provide that will tell will > > treat transactions according to the JPA spec". > > > > We have started to identify some cases where we deviate from the spec[1], > > such as: > > * Strict query compliance. As I mentioned earlier we do have such a > > setting already for this in particular > > * List versus Bag determination from mappings. > > * Closed EMF (SF) handling > > * EntityTransaction status checking - JPA says we should throw exceptions > > whereas we just ignore the call. > > > > We need to decide also which of these we want to just change outright > > versus controlling via a setting. > > > > * Setting > > * Setting, or introduce a new @Bag annotation - the annotation option is > > actually pretty appealing since often times the bag behavior is so > > unexpected from users... > > * I think we should just change the behavior of calling EMF#close on a > > closed EMF. Any application that happens to be relying on us no-op'ing > > this call can easily change that to protect the call with an `#isOpen` > > check. In fact I think we should change all of these to match the JPA > > expectations such that it is an error to call any of the following: > #close, > > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > > #getPersistenceUnitUtil, #createEntityManager. To me these all seem > pretty > > reasonable. And in fact I think we used to handle this all properly from > > the EMF side. I think we just lost that behavior when we changed to have > > our contracts extend the JPA ones since we kept the legacy Hibernate > > behavior in SessionFactory. > > * This one I am very undecided. I can see very valid arguments for each. > > > > [1] we really ought to start keeping a list of these. I have started > > adding them to the migration guide. Just as a list of things we need to > > support configuring or switch to the JPA "way". > > > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > > wrote: > > > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be > >> documenting that a SF obtained from unwrapping an EMF will conform to > the > >> JPA spec in term of exceptions. > >> > >> On 16 November 2017 at 21:09, Vlad Mihalcea > >> wrote: > >> > >>> 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 interface > implementation, > >>> so > >>> a user can define those compatibility methods according to their needs. > >>> > >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 > differences; > >>> > >>> - don't throw exception when closing the ENG twice > >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. > >>> > >>> Vlad > >>> > >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > >>> > >>> > There is already a similar setting, although specific to query > >>> language: >
Re: [hibernate-dev] JPA Compliance
On 24 November 2017 at 17:39, Steve Ebersole wrote: > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > yes but has you pointed out due to the bootstrapping the behaviour of the SF will be strict JPA compliant. > > Another thing I was discussing with Andrea in chat is possibly making > these multi-valued, or having multiple values for this. I can't imagine > the FQN case is really all that appealing to a user. I'm fairly certain a > user would rather simply say "yeah, treat transactions according the JPA > spec" as opposed to "here is a class I will provide that will tell will > treat transactions according to the JPA spec". > > We have started to identify some cases where we deviate from the spec[1], > such as: > * Strict query compliance. As I mentioned earlier we do have such a > setting already for this in particular > * List versus Bag determination from mappings. > * Closed EMF (SF) handling > * EntityTransaction status checking - JPA says we should throw exceptions > whereas we just ignore the call. > > We need to decide also which of these we want to just change outright > versus controlling via a setting. > > * Setting > * Setting, or introduce a new @Bag annotation - the annotation option is > actually pretty appealing since often times the bag behavior is so > unexpected from users... > @Bag seems really a good idea to me but that means changing the current default behaviour, forcing users to change the code, so not sure if we need also a setting. > * I think we should just change the behavior of calling EMF#close on a > closed EMF. Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` > check. In fact I think we should change all of these to match the JPA > expectations such that it is an error to call any of the following: #close, > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty > reasonable. And in fact I think we used to handle this all properly from > the EMF side. I think we just lost that behavior when we changed to have > our contracts extend the JPA ones since we kept the legacy Hibernate > behavior in SessionFactory. > I do not like the EMF#close behaviour, probably a prefer a separate setting for this. > * This one I am very undecided. I can see very valid arguments for each. > probably for such case a setting may be a good option. > > [1] we really ought to start keeping a list of these. I have started > adding them to the migration guide. Just as a list of things we need to > support configuring or switch to the JPA "way". > > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero > wrote: > >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >> documenting that a SF obtained from unwrapping an EMF will conform to the >> JPA spec in term of exceptions. >> >> On 16 November 2017 at 21:09, Vlad Mihalcea >> wrote: >> >>> 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 interface implementation, >>> so >>> a user can define those compatibility methods according to their needs. >>> >>> E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; >>> >>> - don't throw exception when closing the ENG twice >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one. >>> >>> Vlad >>> >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: >>> >>> > 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 PM Vlad Mihalcea >> > >>> > wrote: >>> > >>> >> 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 standard >>> >> >>> >> Maybe we should expose all those cases and group them in some >>> interface >>> >> to allow the user to customize the level of compliance they need. >>> >> >>> >> Vlad >>> >> >>> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> > >>> >> wrote: >>> >> >>> >>> 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 a
Re: [hibernate-dev] JPA Compliance
So then how about the following: 1. Add a multi-valued setting to define various categories of JPA compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values such as: 1. query (strict jpql compliance) 2. txn (transaction handling per spec) 3. close (multiple calls to EMF and EM #close methods) 4. list (no bags) 5. others? 6. all (there should be some form of specifying all) 2. Add @Bag as an explicit declaration of a bag, even if `hibernate.jpa.compliance=list` is specified - that setting just controls how List with no @OrderColumn is interpreted. I vote to delay adding that until 6.0 3. Retain current behavior for "double close" calls unless "close" compliance has been specified. 4. Keep current behavior unless "txn" compliance has been specified On Mon, Nov 27, 2017 at 4:54 AM andrea boriero wrote: > On 24 November 2017 at 17:39, Steve Ebersole wrote: > >> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >> > > yes but has you pointed out due to the bootstrapping the behaviour of the > SF will be strict JPA compliant. > >> >> Another thing I was discussing with Andrea in chat is possibly making >> these multi-valued, or having multiple values for this. I can't imagine >> the FQN case is really all that appealing to a user. I'm fairly certain a >> user would rather simply say "yeah, treat transactions according the JPA >> spec" as opposed to "here is a class I will provide that will tell will >> treat transactions according to the JPA spec". >> >> We have started to identify some cases where we deviate from the spec[1], >> such as: >> * Strict query compliance. As I mentioned earlier we do have such a >> setting already for this in particular >> * List versus Bag determination from mappings. >> * Closed EMF (SF) handling >> * EntityTransaction status checking - JPA says we should throw exceptions >> whereas we just ignore the call. >> >> We need to decide also which of these we want to just change outright >> versus controlling via a setting. >> >> * Setting >> * Setting, or introduce a new @Bag annotation - the annotation option is >> actually pretty appealing since often times the bag behavior is so >> unexpected from users... >> > > @Bag seems really a good idea to me but that means changing the current > default behaviour, forcing users to change the code, so not sure if we need > also a setting. > > >> * I think we should just change the behavior of calling EMF#close on a >> closed EMF. Any application that happens to be relying on us no-op'ing >> this call can easily change that to protect the call with an `#isOpen` >> check. In fact I think we should change all of these to match the JPA >> expectations such that it is an error to call any of the following: #close, >> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >> reasonable. And in fact I think we used to handle this all properly from >> the EMF side. I think we just lost that behavior when we changed to have >> our contracts extend the JPA ones since we kept the legacy Hibernate >> behavior in SessionFactory. >> > > I do not like the EMF#close behaviour, probably a prefer a separate > setting for this. > > >> * This one I am very undecided. I can see very valid arguments for each. >> > > probably for such case a setting may be a good option. > >> >> [1] we really ought to start keeping a list of these. I have started >> adding them to the migration guide. Just as a list of things we need to >> support configuring or switch to the JPA "way". >> >> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >> wrote: >> >>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be >>> documenting that a SF obtained from unwrapping an EMF will conform to the >>> JPA spec in term of exceptions. >>> >>> On 16 November 2017 at 21:09, Vlad Mihalcea >>> wrote: >>> 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 interface implementation, so a user can define those compatibility methods according to their needs. E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; - don't throw exception when closing the ENG twice - use the native Hibernate FlushMode.AUTO instead of the JPA one. Vlad On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > 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" asp
Re: [hibernate-dev] JPA Compliance
That seems fine to me. On 11/27/2017 04:29 PM, Steve Ebersole wrote: > So then how about the following: > > >1. Add a multi-valued setting to define various categories of JPA >compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >such as: >1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) >2. Add @Bag as an explicit declaration of a bag, even if >`hibernate.jpa.compliance=list` is specified - that setting just controls >how List with no @OrderColumn is interpreted. I vote to delay adding that >until 6.0 >3. Retain current behavior for "double close" calls unless "close" >compliance has been specified. >4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the spec[1], >>> such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw exceptions >>> whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> probably for such case a setting may be a good option. >> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be documenting that a SF obtained from unwrapping an EMF will conform to the JPA spec in term of exceptions. On 16 November 2017 at 21:09, Vlad Mihalcea wrote: > 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 interface > implementation, so > a user can define those compatibility methods according to their needs. > > E.g. Maybe someone wants the Strict JPA mode but with just 2 > differences; > > - don't throw exception when closing the ENG twice > - use the native Hibernate FlushMode.AUTO instead of the JPA one. > > Vlad > > On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > >> There is already a similar setting, although specif
Re: [hibernate-dev] JPA Compliance
I don't understand what is the requirement for the @Bag annotation and the `hibernate.jpa.compliance=list` setting. >From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an ordered List. Otherwise, the order is undefined. Is there anything I'm missing about handling Lists according to the JPA spec? Vlad On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole wrote: > So then how about the following: > > >1. Add a multi-valued setting to define various categories of JPA >compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >such as: >1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) >2. Add @Bag as an explicit declaration of a bag, even if >`hibernate.jpa.compliance=list` is specified - that setting just >controls how List with no @OrderColumn is interpreted. I vote to delay >adding that until 6.0 >3. Retain current behavior for "double close" calls unless "close" >compliance has been specified. >4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero > wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the >>> spec[1], such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw >>> exceptions whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> >> probably for such case a setting may be a good option. >> >>> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be documenting that a SF obtained from unwrapping an EMF will conform to the JPA spec in term of exceptions. On 16 November 2017 at 21:09, Vlad Mihalcea wrote: > 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 interface > implementation, so > a user can define those compatibility methods according to their needs. > > E.g. Maybe someone wan
Re: [hibernate-dev] JPA Compliance
It is not about the order but about duplicates. With the following class A { List bsl @JoinTable(name = "A_B", joinColumns = @JoinColumn(name = "A_ID"), inverseJoinColumns = @JoinColumn(name = "B_ID"), ) @ManyToMany public List getBs() { return b; } } class *B*{ List as; @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) public List getAs() { return as; } } and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). On 28 November 2017 at 05:44, Vlad Mihalcea wrote: > I don't understand what is the requirement for the @Bag annotation and the > `hibernate.jpa.compliance=list` setting. > > From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an > ordered List. > Otherwise, the order is undefined. > Is there anything I'm missing about handling Lists according to the JPA > spec? > > Vlad > > On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole > wrote: > >> So then how about the following: >> >> >>1. Add a multi-valued setting to define various categories of JPA >>compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >>such as: >>1. query (strict jpql compliance) >> 2. txn (transaction handling per spec) >> 3. close (multiple calls to EMF and EM #close methods) >> 4. list (no bags) >> 5. others? >> 6. all (there should be some form of specifying all) >>2. Add @Bag as an explicit declaration of a bag, even if >>`hibernate.jpa.compliance=list` is specified - that setting just >>controls how List with no @OrderColumn is interpreted. I vote to delay >>adding that until 6.0 >>3. Retain current behavior for "double close" calls unless "close" >>compliance has been specified. >>4. Keep current behavior unless "txn" compliance has been specified >> >> >> >> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero >> wrote: >> >>> On 24 November 2017 at 17:39, Steve Ebersole >>> wrote: >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >>> yes but has you pointed out due to the bootstrapping the behaviour of >>> the SF will be strict JPA compliant. >>> Another thing I was discussing with Andrea in chat is possibly making these multi-valued, or having multiple values for this. I can't imagine the FQN case is really all that appealing to a user. I'm fairly certain a user would rather simply say "yeah, treat transactions according the JPA spec" as opposed to "here is a class I will provide that will tell will treat transactions according to the JPA spec". We have started to identify some cases where we deviate from the spec[1], such as: * Strict query compliance. As I mentioned earlier we do have such a setting already for this in particular * List versus Bag determination from mappings. * Closed EMF (SF) handling * EntityTransaction status checking - JPA says we should throw exceptions whereas we just ignore the call. We need to decide also which of these we want to just change outright versus controlling via a setting. * Setting * Setting, or introduce a new @Bag annotation - the annotation option is actually pretty appealing since often times the bag behavior is so unexpected from users... >>> >>> @Bag seems really a good idea to me but that means changing the current >>> default behaviour, forcing users to change the code, so not sure if we need >>> also a setting. >>> >>> * I think we should just change the behavior of calling EMF#close on a closed EMF. Any application that happens to be relying on us no-op'ing this call can easily change that to protect the call with an `#isOpen` check. In fact I think we should change all of these to match the JPA expectations such that it is an error to call any of the following: #close, #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty reasonable. And in fact I think we used to handle this all properly from the EMF side. I think we just lost that behavior when we changed to have our contracts extend the JPA ones since we kept the legacy Hibernate behavior in SessionFactory. >>> >>> I do not like the EMF#close behaviour, probably a prefer a separate >>> setting for this. >>> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >>> probably for such case a setting may be a good option. >>> [1] we really ought to start keeping a list of these. I have started adding them to the migration guide. Just as a list of things we need to support configuring or switch to the JPA "way". On Fri, Nov 17, 2017 at 11:06 AM andrea boriero wrote: > I think for 5.3 it's still fine to rely on isJpaBootstrap may be > documenting that a SF obtained from
Re: [hibernate-dev] JPA Compliance
It seems fine to me and I agree to delay the @Bag to 6.0. On 27 November 2017 at 21:29, Steve Ebersole wrote: > So then how about the following: > > >1. Add a multi-valued setting to define various categories of JPA >compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >such as: >1. query (strict jpql compliance) > 2. txn (transaction handling per spec) > 3. close (multiple calls to EMF and EM #close methods) > 4. list (no bags) > 5. others? > 6. all (there should be some form of specifying all) >2. Add @Bag as an explicit declaration of a bag, even if >`hibernate.jpa.compliance=list` is specified - that setting just >controls how List with no @OrderColumn is interpreted. I vote to delay >adding that until 6.0 >3. Retain current behavior for "double close" calls unless "close" >compliance has been specified. >4. Keep current behavior unless "txn" compliance has been specified > > > > On Mon, Nov 27, 2017 at 4:54 AM andrea boriero > wrote: > >> On 24 November 2017 at 17:39, Steve Ebersole wrote: >> >>> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >>> >> >> yes but has you pointed out due to the bootstrapping the behaviour of the >> SF will be strict JPA compliant. >> >>> >>> Another thing I was discussing with Andrea in chat is possibly making >>> these multi-valued, or having multiple values for this. I can't imagine >>> the FQN case is really all that appealing to a user. I'm fairly certain a >>> user would rather simply say "yeah, treat transactions according the JPA >>> spec" as opposed to "here is a class I will provide that will tell will >>> treat transactions according to the JPA spec". >>> >>> We have started to identify some cases where we deviate from the >>> spec[1], such as: >>> * Strict query compliance. As I mentioned earlier we do have such a >>> setting already for this in particular >>> * List versus Bag determination from mappings. >>> * Closed EMF (SF) handling >>> * EntityTransaction status checking - JPA says we should throw >>> exceptions whereas we just ignore the call. >>> >>> We need to decide also which of these we want to just change outright >>> versus controlling via a setting. >>> >>> * Setting >>> * Setting, or introduce a new @Bag annotation - the annotation option is >>> actually pretty appealing since often times the bag behavior is so >>> unexpected from users... >>> >> >> @Bag seems really a good idea to me but that means changing the current >> default behaviour, forcing users to change the code, so not sure if we need >> also a setting. >> >> >>> * I think we should just change the behavior of calling EMF#close on a >>> closed EMF. Any application that happens to be relying on us no-op'ing >>> this call can easily change that to protect the call with an `#isOpen` >>> check. In fact I think we should change all of these to match the JPA >>> expectations such that it is an error to call any of the following: #close, >>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >>> #getPersistenceUnitUtil, #createEntityManager. To me these all seem pretty >>> reasonable. And in fact I think we used to handle this all properly from >>> the EMF side. I think we just lost that behavior when we changed to have >>> our contracts extend the JPA ones since we kept the legacy Hibernate >>> behavior in SessionFactory. >>> >> >> I do not like the EMF#close behaviour, probably a prefer a separate >> setting for this. >> >> >>> * This one I am very undecided. I can see very valid arguments for each. >>> >> >> probably for such case a setting may be a good option. >> >>> >>> [1] we really ought to start keeping a list of these. I have started >>> adding them to the migration guide. Just as a list of things we need to >>> support configuring or switch to the JPA "way". >>> >>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero >>> wrote: >>> I think for 5.3 it's still fine to rely on isJpaBootstrap may be documenting that a SF obtained from unwrapping an EMF will conform to the JPA spec in term of exceptions. On 16 November 2017 at 21:09, Vlad Mihalcea wrote: > 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 interface > implementation, so > a user can define those compatibility methods according to their needs. > > E.g. Maybe someone wants the Strict JPA mode but with just 2 > differences; > > - don't throw exception when closing the ENG twice > - use the native Hibernate FlushMode.AUTO instead of the JPA one. > > Vlad > > On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote:
Re: [hibernate-dev] JPA Compliance
Makes sense. I think it's reasonable to add this since this is what a many-to-many table relationship looks like. But, it's ok to postpone it until 6.0. Vlad On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero wrote: > It is not about the order but about duplicates. > > With the following > class A { >List bsl > @JoinTable(name = "A_B", > joinColumns = @JoinColumn(name = "A_ID"), > inverseJoinColumns = @JoinColumn(name = "B_ID"), > ) > @ManyToMany > public List getBs() { > return b; > } > } > > class *B*{ > List as; > > @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) > public List getAs() { > return as; > } > } > > and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). > > On 28 November 2017 at 05:44, Vlad Mihalcea > wrote: > >> I don't understand what is the requirement for the @Bag annotation and >> the `hibernate.jpa.compliance=list` setting. >> >> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an >> ordered List. >> Otherwise, the order is undefined. >> Is there anything I'm missing about handling Lists according to the JPA >> spec? >> >> Vlad >> >> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole >> wrote: >> >>> So then how about the following: >>> >>> >>>1. Add a multi-valued setting to define various categories of JPA >>>compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values >>>such as: >>>1. query (strict jpql compliance) >>> 2. txn (transaction handling per spec) >>> 3. close (multiple calls to EMF and EM #close methods) >>> 4. list (no bags) >>> 5. others? >>> 6. all (there should be some form of specifying all) >>>2. Add @Bag as an explicit declaration of a bag, even if >>>`hibernate.jpa.compliance=list` is specified - that setting just >>>controls how List with no @OrderColumn is interpreted. I vote to delay >>>adding that until 6.0 >>>3. Retain current behavior for "double close" calls unless "close" >>>compliance has been specified. >>>4. Keep current behavior unless "txn" compliance has been specified >>> >>> >>> >>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero >>> wrote: >>> On 24 November 2017 at 17:39, Steve Ebersole wrote: > Andrea, SF is a EMF. Unwrapping simply returns the same instance. > yes but has you pointed out due to the bootstrapping the behaviour of the SF will be strict JPA compliant. > > Another thing I was discussing with Andrea in chat is possibly making > these multi-valued, or having multiple values for this. I can't imagine > the FQN case is really all that appealing to a user. I'm fairly certain a > user would rather simply say "yeah, treat transactions according the JPA > spec" as opposed to "here is a class I will provide that will tell will > treat transactions according to the JPA spec". > > We have started to identify some cases where we deviate from the > spec[1], such as: > * Strict query compliance. As I mentioned earlier we do have such a > setting already for this in particular > * List versus Bag determination from mappings. > * Closed EMF (SF) handling > * EntityTransaction status checking - JPA says we should throw > exceptions whereas we just ignore the call. > > We need to decide also which of these we want to just change outright > versus controlling via a setting. > > * Setting > * Setting, or introduce a new @Bag annotation - the annotation option > is actually pretty appealing since often times the bag behavior is so > unexpected from users... > @Bag seems really a good idea to me but that means changing the current default behaviour, forcing users to change the code, so not sure if we need also a setting. > * I think we should just change the behavior of calling EMF#close on a > closed EMF. Any application that happens to be relying on us no-op'ing > this call can easily change that to protect the call with an `#isOpen` > check. In fact I think we should change all of these to match the JPA > expectations such that it is an error to call any of the following: > #close, > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, > #getPersistenceUnitUtil, #createEntityManager. To me these all seem > pretty > reasonable. And in fact I think we used to handle this all properly from > the EMF side. I think we just lost that behavior when we changed to have > our contracts extend the JPA ones since we kept the legacy Hibernate > behavior in SessionFactory. > I do not like the EMF#close behaviour, probably a prefer a separate setting for this. > * This one I am very undecided. I can see very valid arguments for > each. > probably for such case a setting may be a good option. > > [
Re: [hibernate-dev] JPA Compliance
Wrt to bag versus list, it's more the inability to fetch multiple bags, which is perfectly legal in JPA but is an exception in Hibernate. If have to search for the exact section, but afair to JPA a List defined as OneToMany or ManyToMany has an implicit OrderColumn if one is not provided. And in this configuration Hibernate has no problem with the multiple fetches. On Tue, Nov 28, 2017, 5:19 AM Vlad Mihalcea wrote: > Makes sense. I think it's reasonable to add this since this is what a > many-to-many table relationship looks like. > > But, it's ok to postpone it until 6.0. > > Vlad > > On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero > wrote: > >> It is not about the order but about duplicates. >> >> With the following >> class A { >>List bsl >> @JoinTable(name = "A_B", >> joinColumns = @JoinColumn(name = "A_ID"), >> inverseJoinColumns = @JoinColumn(name = "B_ID"), >> ) >> @ManyToMany >> public List getBs() { >> return b; >> } >> } >> >> class *B*{ >> List as; >> >> @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL) >> public List getAs() { >> return as; >> } >> } >> >> and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID). >> >> On 28 November 2017 at 05:44, Vlad Mihalcea >> wrote: >> >>> I don't understand what is the requirement for the @Bag annotation and >>> the `hibernate.jpa.compliance=list` setting. >>> >>> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an >>> ordered List. >>> Otherwise, the order is undefined. >>> Is there anything I'm missing about handling Lists according to the JPA >>> spec? >>> >>> Vlad >>> >>> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole >>> wrote: >>> So then how about the following: 1. Add a multi-valued setting to define various categories of JPA compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values such as: 1. query (strict jpql compliance) 2. txn (transaction handling per spec) 3. close (multiple calls to EMF and EM #close methods) 4. list (no bags) 5. others? 6. all (there should be some form of specifying all) 2. Add @Bag as an explicit declaration of a bag, even if `hibernate.jpa.compliance=list` is specified - that setting just controls how List with no @OrderColumn is interpreted. I vote to delay adding that until 6.0 3. Retain current behavior for "double close" calls unless "close" compliance has been specified. 4. Keep current behavior unless "txn" compliance has been specified On Mon, Nov 27, 2017 at 4:54 AM andrea boriero wrote: > On 24 November 2017 at 17:39, Steve Ebersole > wrote: > >> Andrea, SF is a EMF. Unwrapping simply returns the same instance. >> > > yes but has you pointed out due to the bootstrapping the behaviour of > the SF will be strict JPA compliant. > >> >> Another thing I was discussing with Andrea in chat is possibly making >> these multi-valued, or having multiple values for this. I can't imagine >> the FQN case is really all that appealing to a user. I'm fairly certain >> a >> user would rather simply say "yeah, treat transactions according the JPA >> spec" as opposed to "here is a class I will provide that will tell will >> treat transactions according to the JPA spec". >> >> We have started to identify some cases where we deviate from the >> spec[1], such as: >> * Strict query compliance. As I mentioned earlier we do have such a >> setting already for this in particular >> * List versus Bag determination from mappings. >> * Closed EMF (SF) handling >> * EntityTransaction status checking - JPA says we should throw >> exceptions whereas we just ignore the call. >> >> We need to decide also which of these we want to just change outright >> versus controlling via a setting. >> >> * Setting >> * Setting, or introduce a new @Bag annotation - the annotation option >> is actually pretty appealing since often times the bag behavior is so >> unexpected from users... >> > > @Bag seems really a good idea to me but that means changing the > current default behaviour, forcing users to change the code, so not sure > if > we need also a setting. > > >> * I think we should just change the behavior of calling EMF#close on >> a closed EMF. Any application that happens to be relying on us no-op'ing >> this call can easily change that to protect the call with an `#isOpen` >> check. In fact I think we should change all of these to match the JPA >> expectations such that it is an error to call any of the following: >> #close, >> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties, >> #getPersistenceUnitUtil, #createEntityManager. To me t