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

Closed
opened 2026-01-22 15:40:52 +01:00 by admin · 5 comments
Owner

Originally created by @olsavmic on GitHub (Dec 29, 2021).

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 https://github.com/doctrine/orm/pull/9301

Expected behavior

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

Originally created by @olsavmic on GitHub (Dec 29, 2021). ### Bug Report <!-- Fill in the relevant information below to help triage your issue. --> | 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 https://github.com/doctrine/orm/pull/9301 #### Expected behavior All fields of entity should be present in $actualData (and therefore in originalEntityData).
admin closed this issue 2026-01-22 15:40:52 +01:00
Author
Owner

@olsavmic commented on GitHub (Jan 24, 2022):

@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!

@olsavmic commented on GitHub (Jan 24, 2022): @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!
Author
Owner

@beberlei commented on GitHub (Jan 24, 2022):

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

@beberlei commented on GitHub (Jan 24, 2022): 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
Author
Owner

@supersmile2009 commented on GitHub (Jan 27, 2022):

Entity id also goes missing. I addressed both of these issues in my PR quite some time ago. https://github.com/doctrine/orm/pull/7318

@supersmile2009 commented on GitHub (Jan 27, 2022): Entity id also goes missing. I addressed both of these issues in my PR quite some time ago. https://github.com/doctrine/orm/pull/7318
Author
Owner

@olsavmic commented on GitHub (Apr 1, 2022):

@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 commented on GitHub (Apr 1, 2022): @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.
Author
Owner

@olsavmic commented on GitHub (Jun 14, 2022):

Ping @beberlei @derrabus

@olsavmic commented on GitHub (Jun 14, 2022): Ping @beberlei @derrabus
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6895