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.golov...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
