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