Hi,
I agree that Optional should not be used for entity attributes.
Nevertheless, they can still use it for getters if they use field-based
access:
As for the Session-level API, we could add those methods. However, it's
maybe just a syntactic sugar for calling:
Optional.ofNullable(query.uniqueResult());
Vlad
On Thu, May 5, 2016 at 12:24 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
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
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev