[hibernate-dev] 5.2 Java 8 Optional support

Vlad Mihalcea mihalcea.vlad at gmail.com
Fri May 6 01:26:26 EDT 2016


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:

http://stackoverflow.com/questions/24975813/hibernate-orm-supporting-java-1-8-optional-for-persistence

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 at 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 at 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?answertab=votes#tab-top
> >
> >     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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list