On Thu, 16 Apr 2020 at 15:42, Steve Ebersole <st...@hibernate.org> wrote:
>
> Bit off track, but since you mentioned load, etc... Take a look at the
> IdentifierLoadAccess, etc variants for loading. E.g.
>
> interface IdentifierLoadAccess<T> {
> T getReference(Object id);
> T load(Object id);
> Optional<T> loadOptional(Object id);
> }
>
> Granted I'm partial, but I think that's pretty clear :)
Right, that's a very nice API; my "usual confusion" is addressed, and
people can choose if they like dealing with Optional.
> Reactive stuff is a bit different, but from my experience I would never ever
> ever use something like `Optional<TheOtherEntity>` for an association. In
> fact back in the day this was more/less what Top Link did for to-one mappings
> and it was fugly. Not that you are suggesting that per-se.
I wouldn't want to impose ot people that `Optional<TheOtherEntity>` be
"the right way" but I'd like to see it as a reasonable option - when
the association isn't mandated by the schema: FK nullability.
I'm curious, why wouldn't you use it? Just personal taste, or would
you see some problem with it?
Thanks,
Sanne
>
>
> On Thu, Apr 16, 2020 at 9:11 AM Sanne Grinovero <sa...@hibernate.org> wrote:
>>
>> I would agree with you all about the general sentiment against the use
>> of Optional, but there's one use case in which I think it might make
>> sense (although bear with me as I've never really used it much yet) :
>>
>> there's several methods on the standard Session and EntityManager in
>> Hibernate ORM to fetch a single entity: load/find/get/...
>>
>> Even after all these years, I always have to open the Javadoc to
>> remember which ones are making assumptions about the entity existence
>> in the database (so could return a proxy even if the object doesn't
>> actually existin the DB), and which ones are going to check first in
>> the DB, possibly returning null.
>>
>> Wouldn't Optional be great there to express the doubt vs the certainty
>> of it returning something?
>>
>> Similarly in xToOne associations, having to remember to set the
>> "optional" attribute, or having business code having to match the
>> mapping is not ideal. That's perhaps unrelated, as this second point
>> is more about how users should express mappings rather than how we
>> expose APIs, but I mean it as an example to not necessarily go to the
>> extreme of ignoring that it might have some use in some selected
>> cases.
>>
>> Thanks,
>> Sanne
>>
>> On Thu, 16 Apr 2020 at 11:44, Davide D'Alto <daltodav...@gmail.com> wrote:
>> >
>> > Hi,
>> > Gavin sent this PR: https://github.com/hibernate/hibernate-rx/pull/93
>> >
>> > It removes Optional from the API, for example:
>> >
>> > <T> CompletionStage<Optional<T>> fetch(T association);
>> >
>> > becomes:
>> >
>> > <T> CompletionStage<T> fetch(T association);
>> >
>> > Is there anybody here with strong opinions about keeping Optional in the
>> > API?
>> >
>> > Thanks,
>> > Davide
>> > _______________________________________________
>> > 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
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
