DDC-166: When entity is moved from one collection to another, it is still considered "orphaned" #204

Closed
opened 2026-01-22 12:30:30 +01:00 by admin · 6 comments
Owner

Originally created by @doctrinebot on GitHub (Nov 20, 2009).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user ablock:

If I remove an entity from a PersistentCollection, the UnitOfWork marks is as "orphaned" (assuming I set that in my entity). If I then move the entity to another collection, this status doesn't get removed, and the UnitOfWork deletes it.

Originally created by @doctrinebot on GitHub (Nov 20, 2009). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user ablock: If I remove an entity from a PersistentCollection, the UnitOfWork marks is as "orphaned" (assuming I set that in my entity). If I then move the entity to another collection, this status doesn't get removed, and the UnitOfWork deletes it.
admin added the Bug label 2026-01-22 12:30:30 +01:00
admin closed this issue 2026-01-22 12:30:32 +01:00
Author
Owner

@doctrinebot commented on GitHub (Dec 27, 2010):

Comment created by @beberlei:

Hm i think this should be marked as bug

@doctrinebot commented on GitHub (Dec 27, 2010): Comment created by @beberlei: Hm i think this should be marked as bug
Author
Owner

@doctrinebot commented on GitHub (Dec 27, 2010):

Comment created by @beberlei:

Attached a patch to fix this issue, but its not really final yet.

Architectural questions:

  1. Are PersistentCollection::add() and PersistentCollection::remove() the only cases where unscheduleOrphanRemoval() is necessary? What about simple ArrayCollections on a new entity?
  2. What about TO_ONE associations with orphan removal?
@doctrinebot commented on GitHub (Dec 27, 2010): Comment created by @beberlei: Attached a patch to fix this issue, but its not really final yet. Architectural questions: 1. Are PersistentCollection::add() and PersistentCollection::remove() the only cases where unscheduleOrphanRemoval() is necessary? What about simple ArrayCollections on a new entity? 2. What about TO_ONE associations with orphan removal?
Author
Owner

@doctrinebot commented on GitHub (Dec 27, 2010):

Comment created by @beberlei:

Patch that solves the issue with ArrayCollections that cannot unschedule orphan removals themselves.

Now only the problem with ONE_TO_ONE relation persists. However this means we might need a new UnitOfWork instance variable. The reason for this is that the Orphan removal of ONE_TO_ONE is detected in "UnitOfWork::computeChangeSets". We cannot use the current "UnitOfWork::unscheduleOrphanRemoval" for this, since it would fail on the following ordering problem:

  1. Entity B unschedule Orphan Removal
  2. Entity A schedule Orphan Removal again (#fail)
@doctrinebot commented on GitHub (Dec 27, 2010): Comment created by @beberlei: Patch that solves the issue with ArrayCollections that cannot unschedule orphan removals themselves. Now only the problem with ONE_TO_ONE relation persists. However this means we might need a new UnitOfWork instance variable. The reason for this is that the Orphan removal of ONE_TO_ONE is detected in "UnitOfWork::computeChangeSets". We cannot use the current "UnitOfWork::unscheduleOrphanRemoval" for this, since it would fail on the following ordering problem: 1. Entity B unschedule Orphan Removal 2. Entity A schedule Orphan Removal again (#fail)
Author
Owner

@doctrinebot commented on GitHub (Jan 2, 2011):

Comment created by @beberlei:

We discussed this issue and came to the conclusion that this behavior is not a bug rather a documentation issue.

Enabling orphanRemoval=true is the semantical equivalent of saying that the orphan entity is privately owned by the parent. That means it should not be re-used!

If you want to re-use entities you should rather look into explicit $em->remove() calls or using cascade=remove.

I updated the documentation accordingly.

@doctrinebot commented on GitHub (Jan 2, 2011): Comment created by @beberlei: We discussed this issue and came to the conclusion that this behavior is not a bug rather a documentation issue. Enabling orphanRemoval=true is the semantical equivalent of saying that the orphan entity is privately owned by the parent. That means it should not be re-used! If you want to re-use entities you should rather look into explicit $em->remove() calls or using cascade=remove. I updated the documentation accordingly.
Author
Owner

@doctrinebot commented on GitHub (Jan 2, 2011):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Jan 2, 2011): Issue was closed with resolution "Invalid"
Author
Owner

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 2 attachments from Jira into https://gist.github.com/0462974f72618e031f98

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 2 attachments from Jira into https://gist.github.com/0462974f72618e031f98 - [10899_DDC166.patch](https://gist.github.com/0462974f72618e031f98#file-10899_DDC166-patch) - [10900_DDC166-2.patch](https://gist.github.com/0462974f72618e031f98#file-10900_DDC166-2-patch)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#204