Details
Description
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations.
Probably the notify policy is not very popular otherwise the bug would have been reported long time ago.
Adding these lines to the UnitOfWork at line 2004 fixes the issue:
// PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also!
Activity
Oleg Namaka
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Description | It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. |
Oleg Namaka
made changes -
| Description |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. Adding these lines to the UnitOfWork at line 2001 fixes the issue: {code} // PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also! {code} |
Oleg Namaka
made changes -
| Description |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. Adding these lines to the UnitOfWork at line 2001 fixes the issue: {code} // PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also! {code} |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. Adding these lines to the UnitOfWork at line 2001 fixes the issue: {code} // PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also! {code} |
Oleg Namaka
made changes -
| Affects Version/s | 2.1.1 [ 10153 ] | |
| Affects Version/s | 2.2.1 [ 10194 ] |
Oleg Namaka
made changes -
| Description |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. Adding these lines to the UnitOfWork at line 2001 fixes the issue: {code} // PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also! {code} |
It seems that it happens because the UnitOfWork::addToIdentityMap() is not the only way to add an entity to the identity map. It is possible to do it directly by assigning array values (pulling my hair why?) . But the code in that method also adds a property changed listener to an entity. As a result that entity is not persisted properly as it does not have a listener. I spent a lot of time trying to figure out why some of my entities were persisted and others no. That happens for entities of same class with parent - children associations. Probably the notify policy is not very popular otherwise the bug would have been reported long time ago. Adding these lines to the UnitOfWork at line 2004 fixes the issue: {code} // PERF: Inlined & optimized code from UnitOfWork#registerManaged() $newValueOid = spl_object_hash($newValue); $this->entityIdentifiers[$newValueOid] = $associatedId; $this->identityMap[$targetClass->rootEntityName][$relatedIdHash] = $newValue; // new lines -- if ($newValue instanceof NotifyPropertyChanged) { -- $newValue->addPropertyChangedListener($this); -- } //end of new lines $this->entityStates[$newValueOid] = self::STATE_MANAGED; // make sure that when an proxy is then finally loaded, $this->originalEntityData is set also! {code} |
Benjamin Eberlei
made changes -
| Workflow | jira [ 13509 ] | jira-feedback [ 14027 ] |
Benjamin Eberlei
made changes -
| Workflow | jira-feedback [ 14027 ] | jira-feedback2 [ 15891 ] |
Benjamin Eberlei
made changes -
| Workflow | jira-feedback2 [ 15891 ] | jira-feedback3 [ 18147 ] |
Benjamin Eberlei
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 2.3.2 [ 10324 ] | |
| Resolution | Fixed [ 1 ] |
This list may be incomplete, as errors occurred whilst retrieving source from linked applications:
- Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-1690, expand=changesets[-21:-1].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)
Changing the code (Perf & Inline block) to this:
$this->registerManaged($newValue, $associatedId, array($field => $newValue));Also fixed the issue and the performance impact was around 3% during my tests.