4:50 a.m.
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_...
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/b40d1251e385a5fdb018f95...
that reproduce this issue.
Thanks,
Gail
10:30 a.m.
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_...
> 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/b40d1251e385a5fdb018f95...
> that reproduce this issue.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
8:52 a.m.
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.
On Thu, 7 Jan 2021 at 10:31, Christian Beikov <christian.beikov(a)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_...
>
> 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/b40d1251e385a5fdb018f95...
>
> that reproduce this issue.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
11:11 a.m.
On Tue, 12 Jan 2021 at 08:31, andrea boriero <andrea(a)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.beikov(a)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_...
> > >
> > > 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/b40d1251e385a5fdb018f95...
> > >
> > > that reproduce this issue.
> > >
> > > Thanks,
> > > Gail
> > > _______________________________________________
> > > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> > > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > _______________________________________________
> > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
7:49 p.m.
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 <sanne(a)hibernate.org> wrote:
On Tue, 12 Jan 2021 at 08:31, andrea boriero
<andrea(a)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.beikov(a)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_...
> > >
> > > 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/b40d1251e385a5fdb018f95...
> > >
> > > that reproduce this issue.
> > >
> > > Thanks,
> > > Gail
> > > _______________________________________________
> > > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> > > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > _______________________________________________
> > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
1198
days inactive
1205
days old
4 comments
4 participants
participants (4)
-
andrea boriero -
Christian Beikov -
Gail Badner -
Sanne Grinovero