[hibernate-dev] JPA Compliance

[andrea boriero]

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 at gmail.com> 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 at 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.vlad at 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 <steve at 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.vlad at 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 <steve at 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 at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>
> >>>>
> >>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>