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.v...@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 <st...@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 <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
