Various expectation changes in hibernate-core after consolidating hibernate-entitymanager
by Steve Ebersole
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.
10 years, 1 month
Re: [hibernate-dev] 5.2 Java 8 Optional support
by Steve Ebersole
Good point about the design/intention of Optional. I hadn't seen that
before.
I included it here because I have seen requests for it.
Serializability is not an argument for me. Yes *if* you plan on detaching
the model and passing it remotely Serializable is a requirement and
Optional could not be used. But you don't have to detach your model and
pass it remotely, of course. The design/intention angle is much more
compelling to me.
So I agree we should probably remove that part. Which is more than ok with
me :)
On Wed, May 4, 2016, 3:52 PM Andrej Golovnin <andrej.golovnin(a)gmail.com>
wrote:
> Hi Steve,
>
> > 1. Support models which define attributes using Optional
>
> -1. Why:
>
> 1. JPA 2.1 Spec. §2.1 The Entity Class:
> If an entity instance is to be passed by value as a detached
> object (e.g., through a remote interface), the entity class must
> implement the Serializable interface.
>
> Optional is not Serializable. Therefore when you use detached
> entities in your application, then you cannot use Optional as
> field type.
>
> 2. Using Optional as field type is considered a misuse of the API.
> See the comment from Stuart Marks:
>
> http://stackoverflow.com/questions/23454952/uses-for-java8-optional?answe...
>
> IntelliJ IDEA warns you for example when you use Optional
> as field type.
>
> Best regards,
> Andrej Golovnin
>
> > 2. Allow retrieving Objects from Hibernate as Optional
> >
> > The second part is really about allowing users to request that Hibernate
> > return Optional in cases where the result may be null. This will be very
> > targeted to cases where the user ask Hibernate to get an entity, e.g.
> > Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
> > Query#uniqueResult, etc. I am against adding any more overloaded
> > Session#get methods, so I will actually limit that to *LoadAccess#load.
> So
> > here I propose adding:
> >
> > 1. Optional<R> *LoadAccess<R>#loadOptional()
> > 2. Optional<R> Query<R>#uniqueResultOptional()
> >
> >
> > The second part is about accepting Optionals from the user. The biggest
> > use case here is the use of Optional in the application domain model for
> > persistent attributes. Again tis breaks down into 2 concerns:
> >
> > 1. Getting/setting values of such persistent attributes.
> > 2. Appropriately marking column(s) of such persistent attributes
> > nullable (by default, at least)
> >
> > The first concern initially seems like a god candidate for Types, but it
> > really does not fit. I think the better place to deal with this is
> > PropertyAcess and specifically the Getter and Setter it returns. The
> > logical there being that the "type" is still the <T>, not the Optional.
> >
> > Handling column nullability will be a challenge given the current state
> of
> > annotation binding code.
> > Another consideration is accepting Query parameters that are Optional.
> It
> > is a silly idea to pass an Optional as a parameter, I agree. But there
> are
> > places it legitimately comes up:
> >
> > - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is
> an
> > Optional
> > - setProperties( a ) - where a is a bean that defines Optional(s)
> >
> > Anyway, that's the plan and I'm sticking to it (unless I hear feedback).
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
10 years, 1 month
Re: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
by Steve Ebersole
On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic(a)gmail.com>
wrote:
> I am confused how you are "mind mapping" PreparedStatement parameters and
>> entity construction into the same conversation. We are not instantiating
>> entities based on PreparedStatement parameters....
>>
>
> I'm not sure I understand you, I haven't mentioned PreparedStatement
> parameters anywhere.
>
Well you mentioned Java 8 parameters names in the subject. I have no idea
what "Java 8 parameter names" might mean outside of the support added in
Java 8 for named parameter binding. So if that's not what you mean, what
do you mean?
Based on some of your other replies, perhaps you are confusing "parameter
names" (PreparedStatement) and "column names" (ResultSet)?
What you propose is to delay the entity instantiation and create the entity
>> instance from after we have the hydrated state.
>
>
> Yes, the requirement for this to work is that before calling constructor
> you have all arguments and target parameter names available.
>
Right, which precludes lazy loading; which is my point on the Jira.
10 years, 1 month
Re: [hibernate-dev] 5.2 Java 8 Optional support
by Andrej Golovnin
Hi Steve,
> 1. Support models which define attributes using Optional
-1. Why:
1. JPA 2.1 Spec. §2.1 The Entity Class:
If an entity instance is to be passed by value as a detached
object (e.g., through a remote interface), the entity class must
implement the Serializable interface.
Optional is not Serializable. Therefore when you use detached
entities in your application, then you cannot use Optional as
field type.
2. Using Optional as field type is considered a misuse of the API.
See the comment from Stuart Marks:
http://stackoverflow.com/questions/23454952/uses-for-java8-optional?answe...
IntelliJ IDEA warns you for example when you use Optional
as field type.
Best regards,
Andrej Golovnin
> 2. Allow retrieving Objects from Hibernate as Optional
>
> The second part is really about allowing users to request that Hibernate
> return Optional in cases where the result may be null. This will be very
> targeted to cases where the user ask Hibernate to get an entity, e.g.
> Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
> Query#uniqueResult, etc. I am against adding any more overloaded
> Session#get methods, so I will actually limit that to *LoadAccess#load. So
> here I propose adding:
>
> 1. Optional<R> *LoadAccess<R>#loadOptional()
> 2. Optional<R> Query<R>#uniqueResultOptional()
>
>
> The second part is about accepting Optionals from the user. The biggest
> use case here is the use of Optional in the application domain model for
> persistent attributes. Again tis breaks down into 2 concerns:
>
> 1. Getting/setting values of such persistent attributes.
> 2. Appropriately marking column(s) of such persistent attributes
> nullable (by default, at least)
>
> The first concern initially seems like a god candidate for Types, but it
> really does not fit. I think the better place to deal with this is
> PropertyAcess and specifically the Getter and Setter it returns. The
> logical there being that the "type" is still the <T>, not the Optional.
>
> Handling column nullability will be a challenge given the current state of
> annotation binding code.
> Another consideration is accepting Query parameters that are Optional. It
> is a silly idea to pass an Optional as a parameter, I agree. But there are
> places it legitimately comes up:
>
> - setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is an
> Optional
> - setProperties( a ) - where a is a bean that defines Optional(s)
>
> Anyway, that's the plan and I'm sticking to it (unless I hear feedback).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
10 years, 1 month
5.2 Java 8 Optional support
by Steve Ebersole
Since 5.2 is moving to baseline on Java 8 we've been looking at Java 8
features we might leverage in Hibernate and allow users to leverage.
The first one I am tackling is "support for Optional", which will have the
following parts:
1. Support models which define attributes using Optional
2. Allow retrieving Objects from Hibernate as Optional
The second part is really about allowing users to request that Hibernate
return Optional in cases where the result may be null. This will be very
targeted to cases where the user ask Hibernate to get an entity, e.g.
Session#get, Session#find, *LoadAccess#load, Query#getSingleResult,
Query#uniqueResult, etc. I am against adding any more overloaded
Session#get methods, so I will actually limit that to *LoadAccess#load. So
here I propose adding:
1. Optional<R> *LoadAccess<R>#loadOptional()
2. Optional<R> Query<R>#uniqueResultOptional()
The second part is about accepting Optionals from the user. The biggest
use case here is the use of Optional in the application domain model for
persistent attributes. Again tis breaks down into 2 concerns:
1. Getting/setting values of such persistent attributes.
2. Appropriately marking column(s) of such persistent attributes
nullable (by default, at least)
The first concern initially seems like a god candidate for Types, but it
really does not fit. I think the better place to deal with this is
PropertyAcess and specifically the Getter and Setter it returns. The
logical there being that the "type" is still the <T>, not the Optional.
Handling column nullability will be a challenge given the current state of
annotation binding code.
Another consideration is accepting Query parameters that are Optional. It
is a silly idea to pass an Optional as a parameter, I agree. But there are
places it legitimately comes up:
- setParameter( ..., a.getSomeOptional() ) - where getSomeOptional is an
Optional
- setProperties( a ) - where a is a bean that defines Optional(s)
Anyway, that's the plan and I'm sticking to it (unless I hear feedback).
10 years, 1 month
