[hibernate-dev] JPA Compliance

[Vlad Mihalcea]

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