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" <st...@hibernate.org> 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.v...@gmail.com> > 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 <st...@hibernate.org> >> 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 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 <st...@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@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