[hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager

[Vlad Mihalcea]

Great work. Looking forward to checking the changes.

Vlad

On Fri, May 6, 2016 at 9:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> A heads up that this initial 5.2 work has been integrated into master.
> Thanks to Chris and Andrea for helping!
>
> At this point master:
>
>    - Baselines on Java 8
>    - hibernate-entitymanager has been removed, consumed into
>    hibernate-core
>    - A few other odds and ends.
>
>
> On Tue, May 3, 2016 at 1:15 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'll update the docs to match the changes.
>>
>> Vlad
>>
>> On Tue, May 3, 2016 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Vlad, there is one last failure in those documentation
>>> tests: org.hibernate.userguide.flush.AutoFlushTest#testFlushAutoSQLNativeSession
>>>
>>> This is indicative of another change specifically consolidating Query.
>>>
>>> On Sat, Apr 30, 2016 at 9:06 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> We are seeing this too in your documentation tests.  So its ok to just
>>>> change those to wrap the writes/flushes in a transaction?  (they are not
>>>> now)
>>>>
>>>>
>>>> On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's fine if we stick to the JPA spec so that only read ops are
>>>>> allowed to be executed outside of a transactional context. Most
>>>>> applications use either Java EE or Spring, so transaction boundaries are
>>>>> usually enforced anyway.
>>>>>
>>>>> It's also fine to throw an exception if the object being checked
>>>>> within the Persistence Context is not an entity. This might break some
>>>>> existing use cases, but we are covered by the JPA spec :D
>>>>>
>>>>> In the getTransaction() case, I still believe we should offer two
>>>>> strategies: a JPA and a native one, the choice being made based on the
>>>>> current bootstrap procedure or some configuration property.
>>>>>
>>>>> Vlad
>>>>>
>>>>> On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> 2. "Another change in expectation is in regards to operations
>>>>>>> outside of a transaction" - in JPA we can execute queries outside a
>>>>>>> transaction, but any write will fail if there is no transactional context,
>>>>>>> which is reasonable for me too. If Hibernate allows writes outside of a
>>>>>>> transactional context, that's definitely a thing we should not support
>>>>>>> anyway.
>>>>>>>
>>>>>>
>>>>>> Well we'll agree to disagree about the validity of allowing queries
>>>>>> outside the scope of a transaction; it does not matter, because JPA says it
>>>>>> should be allowed, so we have to allow that.
>>>>>>
>>>>>> However, historically Hibernate allowed writes outside the scope of
>>>>>> a transaction as well (auto-commit support), so that is what I am talking
>>>>>> about.  After pulling over HEM logic we now have some test failures due to
>>>>>> tests trying to write data outside of an explicit transaction (
>>>>>> javax.persistence.TransactionRequiredException).
>>>>>>
>>>>>> So I propose we continue to expect that as a failure starting in
>>>>>> 5.2.  For queries we will continue to supports it, but only because JPA
>>>>>> requires us to; not because it is a valid concept.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 3. "Asking a Session if is contains (Session/EntityManager#contains)
>>>>>>> a non-entity" - we can handle this with the separate exception
>>>>>>> handler strategies to retain both JPA and Hibernate behaviors.
>>>>>>>
>>>>>>
>>>>>> Why?  This is exactly the kind of thing I have in mind when I talk
>>>>>> about the unnecessary complexity.  Clearly asking if the Session contains a
>>>>>> boolean e.g. is complete non-sense.  If JPA requires that condition to
>>>>>> throw an exception, why even worry about the other case?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that
>>>>>>> is only allowed for JDBC transactions.  Hibernate always allows it."
>>>>>>> - I'd choose the Hibernate behavior because I don;t see how it can cause
>>>>>>> any issue and it's an enhancement as well.
>>>>>>>
>>>>>>
>>>>>> Well that's great in principle.  But JPA actually requires an
>>>>>> exception be thrown when #getTransaction() is called in the JTA case.  So
>>>>>> there is no simple "just allow it as an extension" solution, we'd have to
>>>>>> specific allow users to opt-in to allowing that.
>>>>>>
>>>>>>
>>>>>
>>