Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-166

When entity is moved from one collection to another, it is still considered "orphaned"

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 2.0-ALPHA3
    • Fix Version/s: 2.0.1
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      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.

      1. DDC166.patch
        3 kB
        Benjamin Eberlei
      2. DDC166-2.patch
        5 kB
        Benjamin Eberlei

        Activity

        Hide
        Benjamin Eberlei added a comment -

        Hm i think this should be marked as bug

        Show
        Benjamin Eberlei added a comment - Hm i think this should be marked as bug
        Hide
        Benjamin Eberlei added a comment -

        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?

        Show
        Benjamin Eberlei added a comment - 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?
        Hide
        Benjamin Eberlei added a comment -

        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)

        Show
        Benjamin Eberlei added a comment - 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)
        Hide
        Benjamin Eberlei added a comment -

        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.

        Show
        Benjamin Eberlei added a comment - 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.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Avi Block
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: