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

[Steve Ebersole]

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