[DDC-2306] Lazy loading associated entity's property causes identity loss when another association is set to fetch="EAGER" Created: 20/Feb/13  Updated: 29/Apr/14  Due: 22/Feb/13  Resolved: 26/Feb/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Critical
Reporter: William Schaller Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: orm, proxy, unitofwork
Environment:

PHP 5.4 - IIS 7.0


Attachments: Zip Archive sandbox-uow-issue.zip    

 Description   

There appears to be a bug in UnitOfWork.php, introduced in Merge pull request #406 from Ocramius/DCOM-96. The relevant section is lines 2479-2495.

In the attached test sandbox, there are 4 entities.

User and Address have a many-many relationship via UserAddress – this more or less duplicates what I have in my actual application. There is another entity that both User and Address refer to in a one-to-many relationship – Zone.

When the Zone relationship on User and Address is set to fetch="LAZY", the problem is absent. When the relationship is set to fetch="EAGER", the problem manifests as such:

When I load a User via $em->find(), and then access properties on a related Address, the identity of the Address is lost. The same is true going in the other direction. I var_dump the Address before accessing its street property, and it shows up properly as an uninitialized proxy with just the id set. After I access the street property of the Address, var_dump shows the proxy is loaded and initialized, with all properties set except the identity, which is now null.

I stepped through the code using XDebug, and found that the referenced lines in UnitOfWork.php are setting the created Address entity's properties incorrectly, removing the identity from the generated entity. It seems to have something to do with the _hints parameter.

I'm not sure what the fix is, because I am not familiar enough with this part of the code and what it is intended to do. I assume that this is not intended behavior.

I've included my test case sandbox, which references ../../../../autoload.php to load Doctrine. This was tested against doctrine2/master as of today.



 Comments   
Comment by Marco Pivetta [ 21/Feb/13 ]

I've created a branch with a fix at https://github.com/Ocramius/doctrine2/compare/hotfix;DDC-2306

Basically, what was happening here is a really nasty one:

The UnitOfWork did consider the `Zone` entity as if it was a `User` entity (not comparing classnames, basically). Since the identifier was also the same in this case, the two entities were compared as if the newly loaded `Zone` had to replace the existing `User` proxy.

Thus, the proxy was marked as un-managed and trashed (and so the identifier was also nulled).

Please pull the branch and give it a try. I'll re-read it tomorrow and then open a PR.

Comment by William Schaller [ 21/Feb/13 ]

This fixes the problem for the test case and for my app. Excellent speedy fix, thanks

Comment by Benjamin Eberlei [ 21/Feb/13 ]

A related Github Pull-Request [GH-585] was opened
https://github.com/doctrine/doctrine2/pull/585

Comment by Benjamin Eberlei [ 26/Feb/13 ]

A related Github Pull-Request [GH-585] was closed
https://github.com/doctrine/doctrine2/pull/585

Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-585] was closed:
https://github.com/doctrine/dbal/pull/585

Generated at Sat Oct 25 18:35:40 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.