Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-531

Collections broken in self-referenced Entities

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-BETA2
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      When dealing with parent / children entities, the UnitOfWork does not always hydrate all data correctly.

      This example generates Group1 and its child Group2. Then Clears the Entity Manager, loads Group2 (so it is in the EM), loads Group1 and then the children of Group1 (Group2 is the child of Group1).
      However the children of Group1 cannot be loaded, because $group4->children is not there:

      Warning: Invalid argument supplied for foreach() in /Users/nico/Projects/test/test.php on line 20

      When calling Debug::dump($group4), I get this:

      object(stdClass)#56 (2) {
        ["__CLASS__"]=>
        string(26) "Proxies\EntitiesGroupProxy"
        ["id"]=>
        string(1) "1"
      }
      

      test.php
      http://pastebin.com/7Q3wwtn6

      Group entity:
      http://pastebin.com/hBj2Emrf

        Activity

        Hide
        Nico Kaiser added a comment -

        If I clear the Entity Manager between lines 17 and 18, it works... Seems like the previously loaded Group is reused (which is perfectly fine), but its associations (or at least its self-referenced associations) are not loaded (neither proxies are generated)...

        Show
        Nico Kaiser added a comment - If I clear the Entity Manager between lines 17 and 18, it works... Seems like the previously loaded Group is reused (which is perfectly fine), but its associations (or at least its self-referenced associations) are not loaded (neither proxies are generated)...
        Hide
        Roman S. Borschel added a comment -

        Thanks for reporting. I will take a look as soon as I find the time.

        Show
        Roman S. Borschel added a comment - Thanks for reporting. I will take a look as soon as I find the time.
        Hide
        Nico Kaiser added a comment -

        Test case for Doctrine\Tests\ORM\Functional\Ticket

        Show
        Nico Kaiser added a comment - Test case for Doctrine\Tests\ORM\Functional\Ticket
        Hide
        Christian Heinrich added a comment -

        It might be worth noting that, after renaming $parent to $parent2, the object is loaded but $item4->children remains empty.

        If $item3 isn't being fetched beforehands, then everything seems to work fine.

        Show
        Christian Heinrich added a comment - It might be worth noting that, after renaming $parent to $parent2, the object is loaded but $item4->children remains empty. If $item3 isn't being fetched beforehands, then everything seems to work fine.
        Hide
        Christian Heinrich added a comment - - edited

        After investigating, it came to my mind that the test submitted uses

        $proxy->publicProperty

        instead of

        $proxy->getPublicProperty()

        Therefore, the proxy is not initialized and thus we get unexpected behaviour. Adding a getter a la "getChildren()" and calling this method only, everything works fine.

        Therefore, I mark this ticket as invalid.

        Show
        Christian Heinrich added a comment - - edited After investigating, it came to my mind that the test submitted uses $proxy->publicProperty instead of $proxy->getPublicProperty() Therefore, the proxy is not initialized and thus we get unexpected behaviour. Adding a getter a la "getChildren()" and calling this method only, everything works fine. Therefore, I mark this ticket as invalid.
        Hide
        Nico Kaiser added a comment -

        Shouldn't these properties be automagically instantiated? In our project, we did use getChildren() and it did not work either (sorry, can't provide test case now, will do on monday).

        I think collections are populated automatically everywhere (you can always use $this->children in entities), so this should work here as well.

        Show
        Nico Kaiser added a comment - Shouldn't these properties be automagically instantiated? In our project, we did use getChildren() and it did not work either (sorry, can't provide test case now, will do on monday). I think collections are populated automatically everywhere (you can always use $this->children in entities), so this should work here as well.
        Hide
        Christian Heinrich added a comment -

        The problem here is, that you're not really using an entity but a proxy object. A proxy object does not initialize its collections, see here: http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#don%27t-use-public-properties-on-entities

        As long as you're using normal entities, the PersistentCollections will normally lazy load, thats true. But as soon as you're using proxies - like in this case - you're running into severe problems. I strongly recommend not using public properties.

        Show
        Christian Heinrich added a comment - The problem here is, that you're not really using an entity but a proxy object. A proxy object does not initialize its collections, see here: http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#don%27t-use-public-properties-on-entities As long as you're using normal entities, the PersistentCollections will normally lazy load, thats true. But as soon as you're using proxies - like in this case - you're running into severe problems. I strongly recommend not using public properties.
        Hide
        Nico Kaiser added a comment -

        You are right - if I use getChildren and a "protected $children", this example works.
        However, if I use inheritance (e.g. SINGLE_TABLE), it breaks again, even if I don't use sub items. I'll update the test case.

        Show
        Nico Kaiser added a comment - You are right - if I use getChildren and a "protected $children", this example works. However, if I use inheritance (e.g. SINGLE_TABLE), it breaks again, even if I don't use sub items. I'll update the test case.
        Hide
        Nico Kaiser added a comment -

        Updated DDC531Test.php to use SINGLE_TABLE inheritance. Breaks again, even if I don't use public members for the collection...

        Show
        Nico Kaiser added a comment - Updated DDC531Test.php to use SINGLE_TABLE inheritance. Breaks again, even if I don't use public members for the collection...
        Hide
        Christian Heinrich added a comment -

        Hi Nico,

        thanks for your response. I will take a look at this issue shortly and will hopefully resolve it before beta2.

        regards
        christian

        Show
        Christian Heinrich added a comment - Hi Nico, thanks for your response. I will take a look at this issue shortly and will hopefully resolve it before beta2. regards christian
        Hide
        Roman S. Borschel added a comment -

        Thanks for your investigation. I tracked down the issue and have a fix pending.

        Note though, that with such an example as in the provided testcase, the parents can never be lazy. That means all parents will be eagerly loaded. Of course you can work around that by eager-joining them in DQL or by using Query::HINT_FORCE_PARTIAL_LOAD and things like that.

        The reason why the parents in the example can not be lazy is because a parent can potentially be of any subtype, so you would not know which proxy to put in. In general, a single-valued association that points to another entity that has mapped subclasses can not be lazy. This "problem" does not occur when the targeted entity has no mapped subclasses (this means it either does not participate in a mapped inheritance hierarchy or it is a leaf in the hierarchy).

        See also: http://www.doctrine-project.org/jira/browse/DDC-357

        Show
        Roman S. Borschel added a comment - Thanks for your investigation. I tracked down the issue and have a fix pending. Note though, that with such an example as in the provided testcase, the parents can never be lazy. That means all parents will be eagerly loaded. Of course you can work around that by eager-joining them in DQL or by using Query::HINT_FORCE_PARTIAL_LOAD and things like that. The reason why the parents in the example can not be lazy is because a parent can potentially be of any subtype, so you would not know which proxy to put in. In general, a single-valued association that points to another entity that has mapped subclasses can not be lazy. This "problem" does not occur when the targeted entity has no mapped subclasses (this means it either does not participate in a mapped inheritance hierarchy or it is a leaf in the hierarchy). See also: http://www.doctrine-project.org/jira/browse/DDC-357
        Show
        Roman S. Borschel added a comment - Fixed in http://github.com/doctrine/doctrine2/commit/616f2eda0af1a15ba205cc5013b5f001c34dfc55
        Hide
        Doctrine Bot added a comment -

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

        Show
        Doctrine Bot added a comment - A related Github Pull-Request [GH-970] was closed: https://github.com/doctrine/doctrine2/pull/970

          People

          • Assignee:
            Roman S. Borschel
            Reporter:
            Nico Kaiser
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: