OK, thanks for the feedback! I've created HHH-14405
<https://hibernate.atlassian.net/browse/HHH-14405> for fixing the
documentation.

I've set the fix version for both HHH-14390
<https://hibernate.atlassian.net/browse/HHH-14390> and HHH-14405
<https://hibernate.atlassian.net/browse/HHH-14405> to 5.4-backlog.

Thanks,
Gail

On Wed, Jan 13, 2021 at 2:12 AM Sanne Grinovero <sa...@hibernate.org> wrote:

> On Tue, 12 Jan 2021 at 08:31, andrea boriero <and...@hibernate.org> wrote:
> >
> > I agree with Christian, the FetchMode should only influence the how and
> not
> > the when of a fetch.
> >
> > If the association is EAGER and annotated with FetchMode.SELECT then it
> > should be loaded immediately using a secondary select.
>
> +1
>
> How and when to load express different needs and can be valid in
> various combinations.
>
> A use case is that one might explicitly want a separate loading event,
> for example to simplify the generated SQL or to make better use of the
> 2LC.
>
> One might still want it EAGERly loaded, so to prepare an object graph
> for detached processing.
>
> >
> > On Thu, 7 Jan 2021 at 10:31, Christian Beikov <
> christian.bei...@gmail.com>
> > wrote:
> >
> > > I agree that this should be supported. Specifying a fetch mode should
> > > IMO not change the fetch type to LAZY or EAGER.
> > >
> > > Am 06.01.2021 um 04:50 schrieb Gail Badner:
> > > > Should it be possible to force an eager association to be loaded by a
> > > > separate query using @Fetch(FetchMode.SELECT)?
> > > >
> > > > I thought that Hibernate supported that for an EAGER association,
> but I
> > > see
> > > > the documentation for FetchMode.SELECT
> > > > <
> > >
> https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#fetching-fetch-annotation
> > > >
> > > > says:
> > > >
> > > > "SELECT
> > > > The association is going to be fetched lazily using a secondary
> select
> > > for
> > > > each individual entity, collection, or join load. It’s equivalent to
> > > > JPA FetchType.LAZY fetching strategy."
> > > >
> > > > The reason I ask is because I am trying to wrap up HHH-13085, which
> will
> > > > change derived IDs mapped as a one-to-one association, currently
> loaded
> > > by
> > > > a separate query, to instead be loaded in the same query that loads
> the
> > > > dependent entity. I want to ensure that it is possible to revert
> back to
> > > > loading that one-to-one association in a separate query after
> HHH-13085
> > > is
> > > > fixed.
> > > >
> > > > Currently, a StackOverflowError is thrown when loading an entity
> with an
> > > ID
> > > > that is an bidirectional eager one-to-one association has
> > > FetchMode.SELECT
> > > > mapped.
> > > >
> > > > @Entity(name = "Foo")public class Foo implements Serializable {
> > > >
> > > >      @Id
> > > >      @GeneratedValue
> > > >      private Long id;
> > > >
> > > >      @OneToOne(mappedBy = "foo", cascade = CascadeType.ALL)
> > > >      private Bar bar;
> > > > }
> > > >
> > > > @Entity(name = "Bar")public class Bar implements Serializable {
> > > > @Id
> > > >      @OneToOne(fetch = FetchType.EAGER)
> > > >      @Fetch(FetchMode.SELECT)
> > > >      @JoinColumn(name = "BAR_ID")
> > > >      private Foo foo;
> > > > }
> > > >
> > > >
> > > > According to the documentation, it sounds like
> @Fetch(FetchMode.SELECT)
> > > > should make the association lazy. Is that really correct?
> > > >
> > > > Could someone please clarify the expected behavior?
> > > >
> > > > I created HHH-14390 <
> https://hibernate.atlassian.net/browse/HHH-14390>
> > > for
> > > > the StackOverflowError. I've pushed some FailureExpected tests
> > > > <
> > >
> https://github.com/hibernate/hibernate-orm/commit/b40d1251e385a5fdb018f9583a83c472d6da4e8f
> > > >
> > > > that reproduce this issue.
> > > >
> > > > Thanks,
> > > > Gail
> > > > _______________________________________________
> > > > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > > > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > > _______________________________________________
> > > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > _______________________________________________
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to