Doctrine 2 - ORM

Collections broken in self-referenced Entities

Details

  • Type: Bug Bug
  • Status: Closed 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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Hide
Permalink
Roman S. Borschel added a comment -

Fixed in http://github.com/doctrine/doctrine2/commit/616f2eda0af1a15ba205cc5013b5f001c34dfc55

Show
Roman S. Borschel added a comment - Fixed in http://github.com/doctrine/doctrine2/commit/616f2eda0af1a15ba205cc5013b5f001c34dfc55

People

  • Assignee:
    Roman S. Borschel
    Reporter:
    Nico Kaiser
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: