x-to-one and fetch behaviour bug? #5274

New Issue

admin · 2026-01-22T15:03:14+01:00

admin commented

2026-01-22 15:03:14 +01:00

Originally created by @jmirandase on GitHub (Sep 26, 2016).

Hi,

I have the following entities

and when I call:

$event_repository->fetchMeetingEventByIdWithMeetingEagerly($id);

The following queries are executed:

209 Execute   SELECT m0_.id AS id_0, m0_.created_at AS created_at_1, m0_.scheduled_at AS scheduled_at_2, m0_.started_at AS started_at_3,
m0_.ended_at AS ended_at_4, m1_.id AS id_5, m1_.title AS title_6, m1_.description AS description_7, m1_.billing_code AS billing_code_8,
m1_.presenter_password AS presenter_password_9, m1_.viewer_password AS viewer_password_10, m1_.attendee_capacity AS attendee_capacity_11,
m1_.notify_by AS notify_by_12, m1_.redirect_to AS redirect_to_13, m1_.organizer_starts_with_video AS organizer_starts_with_video_14,
m1_.organizer_starts_with_audio AS organizer_starts_with_audio_15, m1_.presenter_starts_with_video AS presenter_starts_with_video_16,
m1_.presenter_starts_with_audio AS presenter_starts_with_audio_17, m1_.video_mode AS video_mode_18, m1_.chat_type AS chat_type_19,
m1_.starts_recording AS starts_recording_20, m1_.screen_layout AS screen_layout_21, m0_.meeting_id AS meeting_id_22, m1_.organizer_id AS organizer_id_23 FROM meeting_event m0_ LEFT JOIN meeting m1_ ON m0_.meeting_id = m1_.id WHERE m0_.id = '4'

209 Execute   SELECT t0.id AS id_1, t0.filename AS filename_2, t0.video_file_path AS video_file_path_3, t0.chat_file_path AS chat_file_path_4, t0.created_at AS created_at_5, t0.meeting_event_id AS meeting_event_id_6, t0.organizer_id AS organizer_id_7 FROM recording t0 WHERE t0.meeting_event_id = '4'

209 Execute   SELECT t0.id AS id_1, t0.scheduled_at AS scheduled_at_2, t0.duration AS duration_3, t0.repeats_daily AS repeats_daily_4, t0.repeats_weekly AS repeats_weekly_5, t0.repeats_monthly AS repeats_monthly_6, t0.repeats_yearly AS repeats_yearly_7, t0.meeting_id AS meeting_id_8 FROM meeting_schedule t0 WHERE t0.meeting_id = '1'

I was expecting a single query for this method, however 2 additional queries are executed. And the reason for that is here

I was wondering why is that? Why an inverse side of a x-to-one can never be lazy?. I actually don't need to fetch the data from Recording and MeetingSchedule entities. I think those additional queries are totally unnecessary and a waste or resources. Is there something that I am missing here? Is this the expected behaviour? Have I made a mistake with my annotations even though I don't think this is the case because these are one-to-one associations and the owning side are Recording and MeetingSchedule respectively.

Originally created by @jmirandase on GitHub (Sep 26, 2016). Hi, I have the following [entities](https://gist.github.com/jmirandase/96a4648af758981cd48ea55395eec06c) and when I call: ``` PHP $event_repository->fetchMeetingEventByIdWithMeetingEagerly($id); ``` The following queries are executed: ``` sql 209 Execute SELECT m0_.id AS id_0, m0_.created_at AS created_at_1, m0_.scheduled_at AS scheduled_at_2, m0_.started_at AS started_at_3, m0_.ended_at AS ended_at_4, m1_.id AS id_5, m1_.title AS title_6, m1_.description AS description_7, m1_.billing_code AS billing_code_8, m1_.presenter_password AS presenter_password_9, m1_.viewer_password AS viewer_password_10, m1_.attendee_capacity AS attendee_capacity_11, m1_.notify_by AS notify_by_12, m1_.redirect_to AS redirect_to_13, m1_.organizer_starts_with_video AS organizer_starts_with_video_14, m1_.organizer_starts_with_audio AS organizer_starts_with_audio_15, m1_.presenter_starts_with_video AS presenter_starts_with_video_16, m1_.presenter_starts_with_audio AS presenter_starts_with_audio_17, m1_.video_mode AS video_mode_18, m1_.chat_type AS chat_type_19, m1_.starts_recording AS starts_recording_20, m1_.screen_layout AS screen_layout_21, m0_.meeting_id AS meeting_id_22, m1_.organizer_id AS organizer_id_23 FROM meeting_event m0_ LEFT JOIN meeting m1_ ON m0_.meeting_id = m1_.id WHERE m0_.id = '4' ``` ``` sql 209 Execute SELECT t0.id AS id_1, t0.filename AS filename_2, t0.video_file_path AS video_file_path_3, t0.chat_file_path AS chat_file_path_4, t0.created_at AS created_at_5, t0.meeting_event_id AS meeting_event_id_6, t0.organizer_id AS organizer_id_7 FROM recording t0 WHERE t0.meeting_event_id = '4' ``` ``` sql 209 Execute SELECT t0.id AS id_1, t0.scheduled_at AS scheduled_at_2, t0.duration AS duration_3, t0.repeats_daily AS repeats_daily_4, t0.repeats_weekly AS repeats_weekly_5, t0.repeats_monthly AS repeats_monthly_6, t0.repeats_yearly AS repeats_yearly_7, t0.meeting_id AS meeting_id_8 FROM meeting_schedule t0 WHERE t0.meeting_id = '1' ``` I was expecting a single query for this method, however 2 additional queries are executed. And the reason for that is [here](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2608) I was wondering why is that? Why an inverse side of a x-to-one can never be lazy?. I actually don't need to fetch the data from Recording and MeetingSchedule entities. I think those additional queries are totally unnecessary and a waste or resources. Is there something that I am missing here? Is this the expected behaviour? Have I made a mistake with my annotations even though I don't think this is the case because these are one-to-one associations and the owning side are Recording and MeetingSchedule respectively.

admin commented

2026-01-22 15:03:14 +01:00

@coudenysj commented on GitHub (Sep 27, 2016):

Do the associations need to be bidirectional? I think that should solve the extra queries (if you don't access the properties straight away).

@coudenysj commented on GitHub (Sep 27, 2016): Do the associations need to be bidirectional? I think that should solve the extra queries (if you don't access the properties straight away).

admin commented

2026-01-22 15:03:15 +01:00

@jmirandase commented on GitHub (Sep 28, 2016):

@coudenysj thanks for your suggestion. I think I can get rid of the bidirectional association between MeetingEvent and Recording, but unfortunately it's not possible for Meeting and MeetingSchedule. So if I can't avoid bidirectional associations, it seems that I will end up with extra queries during hydration, is that right?. I haven't tested yet, but this could be really bad for many-to-one associations :(

@jmirandase commented on GitHub (Sep 28, 2016): @coudenysj thanks for your suggestion. I think I can get rid of the bidirectional association between MeetingEvent and Recording, but unfortunately it's not possible for Meeting and MeetingSchedule. So if I can't avoid bidirectional associations, it seems that I will end up with extra queries during hydration, is that right?. I haven't tested yet, but this could be really bad for many-to-one associations :(

admin commented

2026-01-22 15:03:16 +01:00

@coudenysj commented on GitHub (Sep 28, 2016):

The comment was changed from "Inverse side can never be lazy" to "Inverse side of x-to-one can never be lazy" in fe7ef4bbeb (diff-6e8c1c1e78b054ba05e20ea09d877865R1798), but it only applies to OneToOne relations.

@coudenysj commented on GitHub (Sep 28, 2016): The comment was changed from _"Inverse side can never be lazy"_ to _"Inverse side of x-to-one can never be lazy"_ in https://github.com/doctrine/doctrine2/commit/fe7ef4bbeb2b1da767c44b6d31070f1e59854ecd#diff-6e8c1c1e78b054ba05e20ea09d877865R1798, but it only applies to OneToOne relations.

admin commented

2026-01-22 15:03:16 +01:00

@theredled commented on GitHub (Jan 11, 2018):

I have the same problem, it has a huge impact on performance.
And thus some questions:

What is the internal reason?
Why wouldn't Doctrine modify original SQL query so that it retrieves one-to-one linked entities without querying afterwards?
Why isn't it documented?

@theredled commented on GitHub (Jan 11, 2018): I have the same problem, it has a huge impact on performance. And thus some questions: - What is the internal reason? - Why wouldn't Doctrine modify original SQL query so that it retrieves one-to-one linked entities without querying afterwards? - Why isn't it documented?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5274