DDC-69: Print OneToMany Mapping is empty if the next object is the same as the last object #82

New Issue

2026-01-22T12:26:31+01:00

admin commented

2026-01-22 12:26:31 +01:00

Originally created by @doctrinebot on GitHub (Oct 28, 2009).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user purnama:

I attached the Unit Test in this issue. If you run this Test. you will
see that on the iteration, the next object is
empty, if and only if the next object the same as the last object.

I found a really strange behaviour in this case.

i try to debug the generated proxy class on this part

private function _load() {
           if ( ! $this->_loaded) {
               $this->*assoc->load($this->_owner, $this, $this->*em,
$this->_joinColumnValues);
               unset($this->_em);
               unset($this->_owner);
               unset($this->_assoc);
               unset($this->_joinColumnValues);
               $this->_loaded = true;
           }
       }

at the $this->_assoc->load($this->_owner, $this, $this->_em,
$this->_joinColumnValues);
it trying to fill the parent of this (the member variable) with the
corresponding value.

in the mapping class (in this case the OneToOneMapping) everything is
going fine it fill the object with the value, and finish the method
process. but in the proxy class, right after that ->load(..) line the
$this member variable is still null.

it seems like that the $this is not passed by reference (the feature
since PHP 5.0). i try to add an & on the Mapping class
(AssociationMapping and all the inherited class) like this example:

 public function load($sourceEntity, &$targetEntity, $em, array
$joinColumnValues = array())
   {
...
}

well it works.. but.. after it going out from the method scope means
the next line of this method :

       public function getType() {
           $this->_load();
           return parent::getType();
       }

the line parent::getType(); is still null.

it means. the $this on the _load() method scope is different than in
the getType() method scope.

I am doing some patching for this problem.

i send you a patch file from the change that i do to
get rid of this problem

you can see in this code that i'm trying to write the value "again" in
the member variable. but this is the only way right now.

the trade off is. that i need to set the visibility of the member
variable of my impacted Entity class to protected.

please take a look. and give feedback.

Originally created by @doctrinebot on GitHub (Oct 28, 2009). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user purnama: I attached the Unit Test in this issue. If you run this Test. you will see that on the iteration, the next object is empty, if and only if the next object the same as the last object. I found a really strange behaviour in this case. i try to debug the generated proxy class on this part ``` private function _load() { if ( ! $this->_loaded) { $this->*assoc->load($this->_owner, $this, $this->*em, $this->_joinColumnValues); unset($this->_em); unset($this->_owner); unset($this->_assoc); unset($this->_joinColumnValues); $this->_loaded = true; } } ``` at the $this->_assoc->load($this->_owner, $this, $this->_em, $this->_joinColumnValues); it trying to fill the parent of this (the member variable) with the corresponding value. in the mapping class (in this case the OneToOneMapping) everything is going fine it fill the object with the value, and finish the method process. but in the proxy class, right after that ->load(..) line the $this member variable is still null. it seems like that the $this is not passed by reference (the feature since PHP 5.0). i try to add an & on the Mapping class (AssociationMapping and all the inherited class) like this example: ``` public function load($sourceEntity, &$targetEntity, $em, array $joinColumnValues = array()) { ... } ``` well it works.. but.. after it going out from the method scope means the next line of this method : ``` public function getType() { $this->_load(); return parent::getType(); } ``` the line parent::getType(); is still null. it means. the $this on the _load() method scope is different than in the getType() method scope. I am doing some patching for this problem. i send you a patch file from the change that i do to get rid of this problem you can see in this code that i'm trying to write the value "again" in the member variable. but this is the only way right now. the trade off is. that i need to set the visibility of the member variable of my impacted Entity class to protected. please take a look. and give feedback.

admin added the Bug label 2026-01-22 12:26:31 +01:00

admin closed this issue

2026-01-22 12:26:32 +01:00

admin commented

2026-01-22 12:26:32 +01:00

@doctrinebot commented on GitHub (Dec 11, 2009):

Comment created by @beberlei:

Was fixed with another issue, applied test-case.

@doctrinebot commented on GitHub (Dec 11, 2009): Comment created by @beberlei: Was fixed with another issue, applied test-case.

admin commented

2026-01-22 12:26:34 +01:00

@doctrinebot commented on GitHub (Dec 11, 2009):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Dec 11, 2009): Issue was closed with resolution "Fixed"

admin commented

2026-01-22 12:26:34 +01:00

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 2 attachments from Jira into https://gist.github.com/9cd4944ab7605c1e9bdc

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 2 attachments from Jira into https://gist.github.com/9cd4944ab7605c1e9bdc - [10105_AdvancedAssociationTest2.php](https://gist.github.com/9cd4944ab7605c1e9bdc#file-10105_AdvancedAssociationTest2-php) - [10106_doctrine20_proxy.patch](https://gist.github.com/9cd4944ab7605c1e9bdc#file-10106_doctrine20_proxy-patch)

admin referenced this issue

2026-01-22 15:56:21 +01:00

[PR #82] [CLOSED] Moved isInitalized assignment to be after the persister load to prevent bad change set computations #7682

admin referenced this issue

2026-01-22 15:56:21 +01:00

[PR #82] Moved isInitalized assignment to be after the persister load to prevent bad change set computations #7686

Sign in to join this conversation.