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