UnitOfWork->originalEntityData is missing not-modified collections after computeChangeSet

[olsavmic]

Bug Report

Q	A
BC Break	no
Version	2.9.x and newer

Summary

UnitOfWork->computeChangeSet(ClassMetadata $class, $entity) overrides the $this->originalEntityData[$oid] by $actualData constructed inside this class.

Collections that were hydrated from the DB but not overridden ($value instanceof PersistentCollection && $value->getOwner === $entity) are skipped and not present in the $actualData variable.

This causes duplicate inserts and possibly other issues in case of subsequent flushes/computeChangeSet calls.

How to reproduce

See #9301

Expected behavior

All fields of entity should be present in $actualData (and therefore in originalEntityData).

[olsavmic]

@beberlei @derrabus Could you please look at the proposed PR that fixes this quite serious issue? I've rewritten the test cases according to your comment more than 3 weeks ago and I don't want this problem overlooked/issue closed.

Thank you!

[beberlei]

Its a very tricky issue and requires 2h+ of concentrated time, sorry we didnt get to it yet but i want to be thorough with it

[supersmile2009]

Entity id also goes missing. I addressed both of these issues in my PR quite some time ago. #7318

[olsavmic]

@supersmile2009 I don't think that's an issue or at least it's a separate issue since these are auto-generated fields and doctrine handles them just fine in the end.

Whereas for collections, the mapping is broken after the first flush and it may result in very hard to detect bugs that puts data into inconsistent state.

Sorry for bothering you once again @beberlei but I think this issue is hard to prevent from the developers perspective and the data are hard to recover when it actually occurs.

[olsavmic]

Ping @beberlei @derrabus