[hibernate-dev] JPA Compliance

[Steve Ebersole]

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
>>>>
>>>
>>>
>