Avoid conflicts due to spl_object_hash.#5689
Conversation
When merging an entity with a to-many association, it will store the original entity data using the object hash of the to-be-merged entity instead of the managed entity. Since this to-be-merged entity is not managed by Doctrine, it can disappear from the memory. A new object can reuse the same memory location and thus have the same object hash. When one tries to persist this object as new, Doctrine will refuse it because it thinks that the entity is managed+dirty. This patch is a very naive fix: it just disables storing the original entity data in case of to-many associations. It may not be the ideal or even a good solution at all, but it solves the problem of object hash reuse. The test case relies on the immediate reusing of memory locations by PHP. The variable $user has twice the same object hash, though referring a different object. Tested on PHP 5.6.17 Without the fix, the test fails on the last line with: A managed+dirty entity Doctrine\Tests\Models\CMS\CmsUser@[...] can not be scheduled for insertion.
|
In the meanwhile I noticed that #1465 is created for the same issue. |
Seems like an uncovered scenario indeed... |
| $user = new CmsUser(); | ||
| $this->_em->merge($user); | ||
|
|
||
| $user = null; |
There was a problem hiding this comment.
Can you add an assertion that verifies that the spl object hash of $user is NOT in the UnitOfWork at this point in time?
There was a problem hiding this comment.
Right after the null assignment? How do you define "being in the UnitOfWork"?
There was a problem hiding this comment.
Right after the null assignment, yes. Checking these properties should be sufficient, I suppose.
| parent::setUp(); | ||
| } | ||
|
|
||
| public function testOidReuse() |
There was a problem hiding this comment.
Note for whoever gets to merge this: we need to first move the test to the UnitOfWorkTest
…ations-2.5' into 2.5 Close #5689
|
Merged, thanks @mathieudz! |
When merging an entity with a to-many association, it will store the
original entity data using the object hash of the to-be-merged entity
instead of the managed entity. Since this to-be-merged entity is not
managed by Doctrine, it can disappear from the memory. A new object
can reuse the same memory location and thus have the same object hash.
When one tries to persist this object as new, Doctrine will refuse it
because it thinks that the entity is managed+dirty.
This patch is a very naive fix: it just disables storing the original
entity data in case of to-many associations. It may not be the ideal
or even a good solution at all, but it solves the problem of object
hash reuse.
The test case relies on the immediate reusing of memory locations by
PHP. The variable $user has twice the same object hash, though referring
a different object. Tested on PHP 5.6.17
Without the fix, the test fails on the last line with:
A managed+dirty entity Doctrine\Tests\Models\CMS\CmsUser@[...] can not
be scheduled for insertion.