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

Mon Apr 25 05:13:48 EDT 2016

The strategy approach sounds nice on first thought, but it also adds
complexity.

I think the underlying question is: What's the long-term strategy around
the "Classic API"? Should it remain in place for all times as a complete
alternative to the JPA API?

Or should we begin to deprecate it and narrow it down in favour of the
corresponding functionality standardized in JPA, and only functionality not
present in JPA would be exposed through some kind of unwrap()?

Without having thought about all the implications too much, I'd lean
towards the latter, in which case I vote for "1. Just move to JPA expected
exceptions" as part of such larger effort.

It'd be interesting to run a poll to see some figures of people using
classic vs. JPA.

--Gunnar

2016-04-25 10:47 GMT+02:00 andrea boriero <andrea at hibernate.org>:

> Having a Strategy gives us more flexibility  so +1.
>
> About the expectations I think what Vlad says is reasonable.
>
> On 25 April 2016 at 06:04, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> > Your second email summarizes my thoughts as well. If we can separate the
> > exception handling in two separate strategies that are defined during
> > bootstrap (JPA vs Hibernate),
> > I think that's the way to go.
> >
> > There so many projects out there that rely on the exception type being
> > thrown, and changing those would make it very difficult for them to
> migrate
> > to this new version.
> > But that only affects Hibernate-native projects since, for those who have
> > been using JPA, they already expect the JPA exceptions anyway.
> >
> > As for the other behavior discrepancies:
> >
> > 1. "calling EntityManager#close on a closed EntityManager should result
> in
> > an
> > exception;" - that's a reasonable default and shouldn't cause too much
> > trouble.
> > 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.
> > 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.
> > 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.
> >
> > Vlad
> >
> >
> >
> >
> >
> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> > > Just realized that I should have mentioned an important plan that helps
> > > understand the idea behind the "exception handling strategy" route.  I
> > plan
> > > to keep track of how a SessionFactory was bootstrapped in some fashion.
> > So
> > > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA
> > > bootstrap methods leverage) we'd select the "JPA exception handling"
> > > strategy impl.  When not, we'd use the "legacy Hibernate exception
> > > handling" strategy.
> > >
> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole <steve at hibernate.org>
> > > wrote:
> > >
> > > > There are a number of "expectation changes" that come about from
> > > > consolidating hibernate-entitymanger into hibernate-core.  Some we
> have
> > > > discussed; some we have not.  Hopefully we can come to a consensus
> > > regards
> > > > how to deal with these changes...
> > > >
> > > > The first one is different exception types.  We have discussed this
> > > > before.  For now, in an effort to fix test failures and move forward
> > with
> > > > developing, I simply changed failing tests to expect the JPA defined
> > > > exceptions.  I had mentioned, where possible, to to throw a
> combination
> > > of
> > > > the 2 expected exceptions.  Generally this falls into 2 discrete
> > > categories:
> > > >
> > > >
> > > >    1. JPA expects a PersistenceException and we have historically
> > thrown
> > > >    a HibernateException
> > > >    2. JPA expects some form of JDK RuntimeException
> > > >    (IllegalArgumentException, IllegalStateException, etc) and we have
> > > >    historically thrown a HibernateException
> > > >
> > > > It is unfortunate that Java does not allow exceptions to be defined
> by
> > > > means of interfaces; that's the only "clean" way I see to do this -
> > that
> > > > would have allowed us to define concrete exception classes that
> extend
> > > > PersistenceException, IllegalArgumentException, etc and that
> implement
> > > HibernateException.
> > > >
> > > >
> > > > So I see 3 potential solutions (feel free to bring up others).
> > > >
> > > >    1. Just move to JPA expected exceptions.
> > > >    2. Have HibernateException extend PersistenceException and just
> not
> > > >    worry about the change in expectation in regards to that second
> > > category.
> > > >    3. Push exception handling behind a strategy.  This would have to
> > be a
> > > >    pretty specific strategy for very specific cases.
> > > >
> > > > The first and second options are pretty self-explanatory and
> > > > straight-forward so I won't go into detail there.  Just realize that
> > > these
> > > > change the expectation for the user.  They'd have to change their
> code
> > to
> > > > catch these JPA-defined exceptions.
> > > > The other option, I see, is to h
> > > >
> > > > The third option is perfect in theory, but it is very tedious.  For
> > > > example, take the case of trying to perform some operation on a
> closed
> > > > Session/EntityManager.  Hibernate historically threw a
> > HibernateException
> > > > here.  JPA says that should result in an IllegalStateException.  So
> in
> > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd
> > > > call out to the strategy to handle that condition.  Even more,
> > Hibernate
> > > > (historically) and JPA disagree about which methods getting called
> on a
> > > > closed Session/EntityManager should lead to an exception.  For
> example,
> > > > JPA says calling EntityManager#close on a closed EntityManager should
> > > > result in an exception; Hibernate historically did not care if you
> > called
> > > > Session#close on a closed Session.  So that is a special case, and
> > every
> > > > one of those special cases would have to be exposed and handled in
> the
> > > > exception handling strategy in additional to the general cases.
> > > >
> > > > Another change in expectation is in regards to operations outside of
> a
> > > > transaction, which I consider a questionable pattern anyway.
> Hibernate
> > > > historically allowed that; JPA explicitly disallows it.  In a way
> this
> > > > could fall under the exception discussion above, meaning we could
> push
> > > that
> > > > distinction behind the exception handling strategy.  Or we could
> decide
> > > > that we are going to stop supporting that.
> > > >
> > > > There are a lot of other highly questionable things I have seen in
> the
> > > > tests that JPA explicitly disallows that I think we ought to just
> stop
> > > > supporting and opt for the JPA way, although I am open to discussing
> > them
> > > > if any feels strongly about them.  Some of these include:
> > > >
> > > >    - Asking a Session if is contains
> (Session/EntityManager#contains) a
> > > >    non-entity.  Hibernate historically would just return false.  JPA
> > > states
> > > >    that should be an exception.
> > > >    - Accessing Session/EntityManager#getTransaction.  JPA says that
> is
> > > >    only allowed for JDBC transactions.  Hibernate always allows it.
> > > >
> > > > If we go the route of an "exception handling strategy" a lot of the
> > other
> > > > points I mentioned above could just be pushed behind that strategy.
> > But
> > > I
> > > > really want to start looking critically at what we support today that
> > we
> > > > maybe really should not be.
> > > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>