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.

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(a)hibernate.org&gt; 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(a)hibernate.org&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt;: > 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(a)gmail.com&gt; 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(a)hibernate.org&gt; > > 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(a)hibernate.org&gt; > > > 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I agree with Gunnar in that the underlying question here is in how we see the "Hibernate API" long term. However I would consider the following categories: Methods which are Hibernate-only Methods which Hibernate had historically which share a signature with JPA Methods which we added to Hibernate specifically for JPA. Personally, in retrospect, I would say that group (3) unequivocally should have been handled by just throwing the JPA exceptions. In a clean-room impl that's what I would do. So I guess the question is whether we want to look at this as a clean-room impl or if we want to constrain ourselves to the legacy exception types. I do wonder if a hybrid approach may be the best, as touched on before. Namely, where JPA expects an IllegalArgumentException, IllegalStateException, etc we throw those; for the rest we'd have Hibernate exception extend PersistenceException. I think that's a great compromise. I'd also mention that in the IllegalArgumentException, IllegalStateException, etc cases there are a few places where HibernateExceptions cover the JPA case already. E.g. JPA says that if there is a problem with the JPQL query (String) used to create a Query an IllegalArgumentException should be thrown; Hibernate currently handles this by throwing a QuerySyntaxException - we could just make QuerySyntaxException extend from IllegalArgumentException rather than Hibernate's HibernateException hierarchy. I think the bottom line is that having Session and EntityManager split before caused all kinds of difficult-to-debug complexity that I'd rather avoid as we consolidate them together. On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > Gunnar's words seem wise to me: users will need to have the JPA API on > classpath anyway, so I don't see why we should have - and maintain - > strategies for different kind of exceptions. > > This might have been useful in the past, but looking forward? > > If the reasoning is that Hibernate - having more features - could > throw more specific and informative exceptions, we could have some > Hibernate exceptions to subclass the JPA ones? > > Would be nice to avoid breaking the expected exception types in a > minor, so I'm not sure if you can do that in all cases by subclassing > the JPA ones, but I suspect it can get you a long way. > > > On 25 April 2016 at 10:13, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > 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(a)hibernate.org&gt;: > > > >> 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(a)gmail.com&gt; > >> 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(a)hibernate.org&gt; > >> > 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(a)hibernate.org&gt; > >> > > 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(a)lists.jboss.org > >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I agree with that to an extent. However there is also a balance - clearly any added complexity has a direct correlation to likelihood of errors/bugs. We just have to find that balance :) On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > N.B. that chancing the exception types thrown by our native methods is > an API change in my opinion. > > So while I think you can have some Hibernate exceptions now extend > some of the types expected by JPA, a fully "clean room" approach is > not something I'd do in a minor release. > > On 25 April 2016 at 15:25, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > I agree with Gunnar in that the underlying question here is in how we > see > > the "Hibernate API" long term. However I would consider the following > > categories: > > > > Methods which are Hibernate-only > > Methods which Hibernate had historically which share a signature with > JPA > > Methods which we added to Hibernate specifically for JPA. > > > > > > Personally, in retrospect, I would say that group (3) unequivocally > should > > have been handled by just throwing the JPA exceptions. In a clean-room > impl > > that's what I would do. > > > > So I guess the question is whether we want to look at this as a > clean-room > > impl or if we want to constrain ourselves to the legacy exception > types. I > > do wonder if a hybrid approach may be the best, as touched on before. > > Namely, where JPA expects an IllegalArgumentException, > > IllegalStateException, etc we throw those; for the rest we'd have > Hibernate > > exception extend PersistenceException. I think that's a great > compromise. > > > > I'd also mention that in the IllegalArgumentException, > > IllegalStateException, etc cases there are a few places where > > HibernateExceptions cover the JPA case already. E.g. JPA says that if > there > > is a problem with the JPQL query (String) used to create a Query an > > IllegalArgumentException should be thrown; Hibernate currently handles > this > > by throwing a QuerySyntaxException - we could just make > QuerySyntaxException > > extend from IllegalArgumentException rather than Hibernate's > > HibernateException hierarchy. > > > > I think the bottom line is that having Session and EntityManager split > > before caused all kinds of difficult-to-debug complexity that I'd rather > > avoid as we consolidate them together. > > > > > > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > >> > >> Gunnar's words seem wise to me: users will need to have the JPA API on > >> classpath anyway, so I don't see why we should have - and maintain - > >> strategies for different kind of exceptions. > >> > >> This might have been useful in the past, but looking forward? > >> > >> If the reasoning is that Hibernate - having more features - could > >> throw more specific and informative exceptions, we could have some > >> Hibernate exceptions to subclass the JPA ones? > >> > >> Would be nice to avoid breaking the expected exception types in a > >> minor, so I'm not sure if you can do that in all cases by subclassing > >> the JPA ones, but I suspect it can get you a long way. > >> > >> > >> On 25 April 2016 at 10:13, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> > 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(a)hibernate.org&gt;: > >> > > >> >> 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(a)gmail.com&gt; > >> >> 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(a)hibernate.org&gt; > >> >> > 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(a)hibernate.org&gt; > >> >> > > 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(a)lists.jboss.org > >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > > > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > > >> >> _______________________________________________ > >> >> hibernate-dev mailing list > >> >> hibernate-dev(a)lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 25 April 2016 at 16:28, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I agree with that to an extent. However there is also a balance - clearly > any added complexity has a direct correlation to likelihood of errors/bugs. > We just have to find that balance :) Of course :) Just pointing this out as there was mention of "clean room" design. > > On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> >> N.B. that chancing the exception types thrown by our native methods is >> an API change in my opinion. >> >> So while I think you can have some Hibernate exceptions now extend >> some of the types expected by JPA, a fully "clean room" approach is >> not something I'd do in a minor release. >> >> On 25 April 2016 at 15:25, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> > I agree with Gunnar in that the underlying question here is in how we >> > see >> > the "Hibernate API" long term. However I would consider the following >> > categories: >> > >> > Methods which are Hibernate-only >> > Methods which Hibernate had historically which share a signature with >> > JPA >> > Methods which we added to Hibernate specifically for JPA. >> > >> > >> > Personally, in retrospect, I would say that group (3) unequivocally >> > should >> > have been handled by just throwing the JPA exceptions. In a clean-room >> > impl >> > that's what I would do. >> > >> > So I guess the question is whether we want to look at this as a >> > clean-room >> > impl or if we want to constrain ourselves to the legacy exception types. >> > I >> > do wonder if a hybrid approach may be the best, as touched on before. >> > Namely, where JPA expects an IllegalArgumentException, >> > IllegalStateException, etc we throw those; for the rest we'd have >> > Hibernate >> > exception extend PersistenceException. I think that's a great >> > compromise. >> > >> > I'd also mention that in the IllegalArgumentException, >> > IllegalStateException, etc cases there are a few places where >> > HibernateExceptions cover the JPA case already. E.g. JPA says that if >> > there >> > is a problem with the JPQL query (String) used to create a Query an >> > IllegalArgumentException should be thrown; Hibernate currently handles >> > this >> > by throwing a QuerySyntaxException - we could just make >> > QuerySyntaxException >> > extend from IllegalArgumentException rather than Hibernate's >> > HibernateException hierarchy. >> > >> > I think the bottom line is that having Session and EntityManager split >> > before caused all kinds of difficult-to-debug complexity that I'd rather >> > avoid as we consolidate them together. >> > >> > >> > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero <sanne(a)hibernate.org&gt; >> > wrote: >> >> >> >> Gunnar's words seem wise to me: users will need to have the JPA API on >> >> classpath anyway, so I don't see why we should have - and maintain - >> >> strategies for different kind of exceptions. >> >> >> >> This might have been useful in the past, but looking forward? >> >> >> >> If the reasoning is that Hibernate - having more features - could >> >> throw more specific and informative exceptions, we could have some >> >> Hibernate exceptions to subclass the JPA ones? >> >> >> >> Would be nice to avoid breaking the expected exception types in a >> >> minor, so I'm not sure if you can do that in all cases by subclassing >> >> the JPA ones, but I suspect it can get you a long way. >> >> >> >> >> >> On 25 April 2016 at 10:13, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> > 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(a)hibernate.org&gt;: >> >> > >> >> >> 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(a)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(a)hibernate.org&gt; >> >> >> > 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(a)hibernate.org&gt; >> >> >> > > 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(a)lists.jboss.org >> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > > >> >> >> > _______________________________________________ >> >> >> > hibernate-dev mailing list >> >> >> > hibernate-dev(a)lists.jboss.org >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> >> >> _______________________________________________ >> >> >> hibernate-dev mailing list >> >> >> hibernate-dev(a)lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev(a)lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

I'd add this as well... I believe that in most of the cases here we are talking about (passing in a bad query, closing a closed Session, etc) these exceptions are of the "checked" sort, meaning they are easily identifiable prior to deployment. Which IMO helps mitigate somewhat the difficulty handling a change in exception type

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.

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. > >

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. >>> >>> >>

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.vlad(a)gmail.com&gt; wrote: > 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. >>>>> >>>>> >>>> >