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

[Steve Ebersole]

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