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 <st...@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.v...@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 <st...@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. >>> >>> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
