DDC-501: Merging entities that contained unloaded proxy collections will delete those associations #624

Closed
opened 2026-01-22 12:44:58 +01:00 by admin · 7 comments
Owner

Originally created by @doctrinebot on GitHub (Apr 8, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user markus.woessner:

If loading an entity without its -to-many-collections, detaching and merging it back WITHOUT having touched those associations will result in two strange behaviours:

oneToMany (bidrectional, mapped by loaded entity): After merge the collection remains empty. Flushing EM and reloading entity will reveal associated entities again

manyToMany (bidirectional, mapped by targeted entity): After merge the collection remains empty. Flushing EM will physically delete associations.

  • ----------------- !! NOTE !! --------------------
  • To reproduce the manyToMany-Bug it's necessary
  • to cascade "merge" on cmUser::groups

Originally created by @doctrinebot on GitHub (Apr 8, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user markus.woessner: If loading an entity without its -to-many-collections, detaching and merging it back WITHOUT having touched those associations will result in two strange behaviours: oneToMany (bidrectional, mapped by loaded entity): After merge the collection remains empty. Flushing EM and reloading entity will reveal associated entities again manyToMany (bidirectional, mapped by targeted entity): After merge the collection remains empty. Flushing EM will physically delete associations. - ----------------- !! NOTE !! -------------------- - To reproduce the manyToMany-Bug it's necessary - to cascade "merge" on cmUser::groups - -------------------------------------------------
admin added the Bug label 2026-01-22 12:44:58 +01:00
admin closed this issue 2026-01-22 12:44:59 +01:00
Author
Owner

@doctrinebot commented on GitHub (Apr 8, 2010):

Comment created by markus.woessner:

Forgot to tell trunk revision

@doctrinebot commented on GitHub (Apr 8, 2010): Comment created by markus.woessner: Forgot to tell trunk revision
Author
Owner

@doctrinebot commented on GitHub (May 12, 2010):

Comment created by shurakai:

This issue is mainly caused by the entity not being initialized before serialization. Additionally, the PersistenCollection does loose all information that is needed to regain the kept entities because the collection itself is not initialized before serialization.

I've added an initialization call here 6c185a2891 (diff-0)

However, I'm not sure whether this is the best solution. Any thoughts?

@doctrinebot commented on GitHub (May 12, 2010): Comment created by shurakai: This issue is mainly caused by the entity not being initialized before serialization. Additionally, the PersistenCollection does loose all information that is needed to regain the kept entities because the collection itself is not initialized before serialization. I've added an initialization call here http://github.com/Shurakai/doctrine2/commit/6c185a2891111dfbd83d381bad8c5a2b16536cad#diff-0 However, I'm not sure whether this is the best solution. Any thoughts?
Author
Owner

@doctrinebot commented on GitHub (May 13, 2010):

Comment created by romanb:

@Christian: I looked at the testcase you committed there and the assumptions it makes are not correct. The original test case provided by Markus made the right assumptions, that is, after the user is unserialized it can and should not know about its groups or phonenumbers since these were not serialized.
When you serialize an entity, you serialize a partial snapshot of its state. When you unserialize it you have all the state that was loaded prior to serialization but you can not get at the rest, the object is detached from the rest of the object graph. Thats where merge() comes in, it reattaches a detached entity to a managed environment where associations can be lazy-loaded, state changes are tracked, etc.

So the problem must come later, at the point of merging.

@doctrinebot commented on GitHub (May 13, 2010): Comment created by romanb: @Christian: I looked at the testcase you committed there and the assumptions it makes are not correct. The original test case provided by Markus made the right assumptions, that is, after the user is unserialized it can and should not know about its groups or phonenumbers since these were not serialized. When you serialize an entity, you serialize a partial snapshot of its state. When you unserialize it you have all the state that was loaded prior to serialization but you can not get at the rest, the object is detached from the rest of the object graph. Thats where merge() comes in, it reattaches a detached entity to a managed environment where associations can be lazy-loaded, state changes are tracked, etc. So the problem must come later, at the point of merging.
Author
Owner

@doctrinebot commented on GitHub (Jun 3, 2010):

Comment created by romanb:

Pushing back to beta3.

@doctrinebot commented on GitHub (Jun 3, 2010): Comment created by romanb: Pushing back to beta3.
Author
Owner

@doctrinebot commented on GitHub (Jul 1, 2010):

Comment created by @beberlei:

Fixed.

@doctrinebot commented on GitHub (Jul 1, 2010): Comment created by @beberlei: Fixed.
Author
Owner

@doctrinebot commented on GitHub (Jul 1, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jul 1, 2010): Issue was closed with resolution "Fixed"
Author
Owner

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

Imported 1 attachments from Jira into https://gist.github.com/484248d59d9ed304e134

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/484248d59d9ed304e134 - [10562_DetachedPartiallyLoadedEntityTest.php](https://gist.github.com/484248d59d9ed304e134#file-10562_DetachedPartiallyLoadedEntityTest-php)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#624