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

[Steve Ebersole]

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