http://www.doctrine-project.org/jira/browse/DDC-3619
When using SoftDeleteable doctrine extension, an entity can be scheduled
for deletion, then persisted before flushing. In such a case, the entity
was removed from the unit of work identity map and no reference was
hold. This could lead to spl_object_hash collisions, and prevent
another, new entity to be persisted later.
This fix makes sure the unit of work identity map holds a reference to
the entity after it has been soft-deleted.
When calling UnitOfWork#recomputeSingleEntityChangeSet on an entity
that didn't have a changeset before, the computation was ignored.
This method however is suggested to be used in "onFlush" and "preFlush"
events in the documentation.
Also fix a bug where recomputeSingleEntityChangeSet was used
before calculating a real changeset for an object.
The fix for DDC-2624 had a side effect on recomputation of
changesets in preUpdate events. The method wasn't adjusted
to the changes in its sister method computeChangeSet() and
had wrong assumptions about the computation.
Especially:
1. Collections have to be skipped
2. Comparison was changed to strict equality only.
Visited collections are cleared only in commit(). Commit clears up only if it actually has something to do. Processing large amounts of records without changing them cause visitedCollections to grow without any way of clearing.
I ran into that problem while I had two objects in the identitymap while hydrating a collection: one was new a "real" entity and the other one was an uninitialized proxy. For "real" entities the em is injected in line 2427, for new entities it is injected in 2436->2364, but for proxies this is missing. According to the comment "inject ObjectManager into just loaded proxies." the code in line 2427 should do this, but in fact it is just used if it is a "real" entity or an already initialized proxy. Moving the injection to outside of the condition in line 2411 (if the entity is an unitialized proxy) solves this.
