Great work. Looking forward to checking the changes.
Vlad
On Fri, May 6, 2016 at 9:34 PM, Steve Ebersole <steve(a)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(a)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(a)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(a)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(a)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(a)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.
>>>>>
>>>>>
>>>>
>