Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2306

Lazy loading associated entity's property causes identity loss when another association is set to fetch="EAGER"

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: Git Master
    • Fix Version/s: 2.4
    • Component/s: ORM
    • Security Level: All
    • Labels:
    • Environment:
      PHP 5.4 - IIS 7.0

      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.

        Activity

        William Schaller created issue -
        William Schaller made changes -
        Field Original Value New Value
        Description There appears to be a bug in UnitOfWork.php, introduced in [this commit by Ocramius|https://github.com/doctrine/doctrine2/blob/8272ffd23fd66bac13a0dc074c868a00b82c7707/lib/Doctrine/ORM/UnitOfWork.php#L2495]. 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.
        There appears to be a bug in UnitOfWork.php, introduced in [Merge pull request #406 from Ocramius/DCOM-96|https://github.com/doctrine/doctrine2/commit/afee16e56bae9bfe93c96ef1398f077e534962a0#L9R2473]. 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.
        Marco Pivetta made changes -
        Assignee Benjamin Eberlei [ beberlei ] Marco Pivetta [ ocramius ]
        Marco Pivetta made changes -
        Fix Version/s 2.4 [ 10321 ]
        Due Date 22/Feb/13
        Marco Pivetta made changes -
        Status Open [ 1 ] Awaiting Feedback [ 10000 ]
        Marco Pivetta made changes -
        Status Awaiting Feedback [ 10000 ] In Progress [ 3 ]
        Marco Pivetta made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Marco Pivetta
            Reporter:
            William Schaller
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: