12:42 p.m.
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
4:10 p.m.
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 <daltodavide(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:42 p.m.
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 :)
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.
On Thu, Apr 16, 2020 at 9:11 AM Sanne Grinovero <sanne(a)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 <daltodavide(a)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(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
5:23 p.m.
On Thu, 16 Apr 2020 at 15:42, Steve Ebersole <steve(a)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 <sanne(a)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 <daltodavide(a)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(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
>
1477
days inactive
1477
days old
3 comments
3 participants
participants (3)
-
Davide D'Alto -
Sanne Grinovero -
Steve Ebersole