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 <mihalcea.vlad(a)gmail.com&gt; 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" <steve(a)hibernate.org&gt; 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 <mihalcea.vlad(a)gmail.com&gt; > > 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 <steve(a)hibernate.org&gt; > >> 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.vlad(a)gmail.com&gt; > >>> 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 <steve(a)hibernate.org > > > >>>> 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(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> > >>>> > >>>> > >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >