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

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&gt; 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&gt; > 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&gt; >> 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&gt; >>> 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. >>>> >>>> >>>