Order of accessing related lazy loaded relations on closed entity manager #6106

New Issue

admin · 2026-01-22T15:26:50+01:00

admin commented

2026-01-22 15:26:50 +01:00

Originally created by @sserbin on GitHub (Nov 19, 2018).

Bug Report

Q	A
BC Break	no
Version	2.6.2

Summary

Probably easier demonstrated via test case. Basically, if you have a loaded entity (a) and close em and it's relations(b,c) are not loaded yet and (b) relates to (c) then accessing(loading) methods on (c) first would break the internal (proxy?) state of (b). Accessing in order of (b),(c) however would work just fine

Current behavior

Order of operations matters

How to reproduce

https://gist.github.com/sserbin/bd0c685b90d8b73f5d04cbc2307c07bd

Expected behavior

Order of operation does not matter, internal object state is not lost/broken

upd: let me know if I should create a pull request with the test case (not sure on the process)

Originally created by @sserbin on GitHub (Nov 19, 2018). ### Bug Report  | Q | A |------------ | ------ | BC Break | no | Version | 2.6.2 #### Summary Probably easier demonstrated via test case. Basically, if you have a loaded entity (a) and close em and it's relations(b,c) are not loaded yet and (b) relates to (c) then accessing(loading) methods on (c) *first* would break the internal (proxy?) state of (b). Accessing in order of (b),(c) however would work just fine #### Current behavior Order of operations matters #### How to reproduce https://gist.github.com/sserbin/bd0c685b90d8b73f5d04cbc2307c07bd #### Expected behavior Order of operation does not matter, internal object state is not lost/broken upd: let me know if I should create a pull request with the test case (not sure on the process)

admin commented

2026-01-22 15:26:50 +01:00

@Ocramius commented on GitHub (Nov 19, 2018):

Does this also apply to ORM master?

@Ocramius commented on GitHub (Nov 19, 2018): Does this also apply to ORM `master`?

admin commented

2026-01-22 15:26:50 +01:00

@sserbin commented on GitHub (Nov 19, 2018):

@Ocramius yes, although the behaviour is slightly different (it's almost the opposite of 2.6 except none of the orders works properly):

# both are null, both assertions fail
$this->assertEquals('the organization', $inv->organization->name); # null
$this->assertEquals('john doe', $inv->account->name); # null

# account->name is null, organization->name is correct
$this->assertEquals('john doe', $inv->account->name); # null
$this->assertEquals('the organization', $inv->organization->name); # correct

here's the full test file: https://gist.github.com/sserbin/1904116d9cd241af7af06f68569f7cad

@sserbin commented on GitHub (Nov 19, 2018): @Ocramius yes, although the behaviour is slightly different (it's almost the opposite of 2.6 except none of the orders works properly): ```php # both are null, both assertions fail $this->assertEquals('the organization', $inv->organization->name); # null $this->assertEquals('john doe', $inv->account->name); # null # account->name is null, organization->name is correct $this->assertEquals('john doe', $inv->account->name); # null $this->assertEquals('the organization', $inv->organization->name); # correct ``` here's the full test file: https://gist.github.com/sserbin/1904116d9cd241af7af06f68569f7cad

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#6106