Section of the Association Mapping document might be wrong #5545

Open
opened 2026-01-22 15:10:56 +01:00 by admin · 6 comments
Owner

Originally created by @bitwombat on GitHub (May 21, 2017).

The section of the docs that talks about the decision of picking an owning side of a ManyToMany relationship might be misleading (or wrong?).

The code included is the synchronization code that a bidirectional association might require. My understanding is that, while the owning side is the one watched for changes, the user-called setter method can be on either side (and just has to call the other side to keep things in sync).

Thus, the code sample shows how to set up the sync functions to reflect the logic of the domain, not how to pick which is the owning side in a ManyToMany association.

Originally created by @bitwombat on GitHub (May 21, 2017). The section of the docs [that talks about the decision](http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#owning-and-inverse-side-on-a-manytomany-association) of picking an owning side of a ManyToMany relationship might be misleading (or wrong?). The code included is the synchronization code that a bidirectional association might require. My understanding is that, while the owning side is the one watched for changes, the user-called setter method can be on either side (and just has to call the other side to keep things in sync). Thus, the code sample shows how to set up the sync functions to reflect the logic of the domain, not how to pick which is the owning side in a ManyToMany association.
admin added the BugDocumentation labels 2026-01-22 15:10:56 +01:00
Author
Owner

@Ocramius commented on GitHub (May 21, 2017):

Ah yes, the setters should handle both sides. I wrote this gist ages ago because of this.

@Ocramius commented on GitHub (May 21, 2017): Ah yes, the setters should handle both sides. I wrote [this gist](https://gist.github.com/Ocramius/3121916) ages ago because of this.
Author
Owner

@bitwombat commented on GitHub (May 21, 2017):

Ah yes, the setters should handle both sides

I don't think that's what this is about. The documentation covers this elsewhere... your gist I think is the same idea as what's in the docs.

I'm asserting that sync functions are independent of which side is the owning side... if that's technically true, then I think the referred section of the docs is wrong/misleading.

@bitwombat commented on GitHub (May 21, 2017): > Ah yes, the setters should handle both sides I don't think that's what this is about. The documentation covers this elsewhere... your gist I think is the same idea as what's in the docs. I'm asserting that sync functions are independent of which side is the owning side... if that's technically true, then I think the referred section of the docs is wrong/misleading.
Author
Owner

@jelomada commented on GitHub (Aug 29, 2017):

I think I found another mistake in same documentation's section:
http://docs.doctrine-project.org/en/latest/reference/association-mapping.html#one-to-one-bidirectional
The last sentence (just before 5.4 headline) says:
"We had a choice of sides on which to place the mappedBy attribute. Because it is on the Cart, that is the owning side of the relation, and thus holds the foreign key."
It should be "inversedBy", not "mappedBy", or I'm really don't understand this at all.

@jelomada commented on GitHub (Aug 29, 2017): I think I found another mistake in same documentation's section: http://docs.doctrine-project.org/en/latest/reference/association-mapping.html#one-to-one-bidirectional The last sentence (just before 5.4 headline) says: "We had a choice of sides on which to place the mappedBy attribute. Because it is on the Cart, that is the owning side of the relation, and thus holds the foreign key." It should be "inversedBy", not "mappedBy", or I'm really don't understand this at all.
Author
Owner

@bitwombat commented on GitHub (Aug 31, 2017):

I think it's correct. The attribute "mappedBy" is on the Cart targetEntity in the metadata within the Customer class.

As is, the code definitely defines the Cart as the owning side... but more commonly it's recognized by noticing that the Cart's $customer property has an "inversedBy" attribute. That's what I look for, at least.

This stuff is necessarily confusing because there are things pointing back to things pointing at the same thigns. Someone chime in if what I've written above is wrong.

@bitwombat commented on GitHub (Aug 31, 2017): I think it's correct. The attribute "mappedBy" is _on_ the Cart targetEntity in the metadata within the Customer class. As is, the code definitely defines the Cart as the owning side... but more commonly it's recognized by noticing that the Cart's $customer property has an "inversedBy" attribute. That's what I look for, at least. This stuff is necessarily confusing because there are things pointing back to things pointing at the same thigns. Someone chime in if what I've written above is wrong.
Author
Owner

@bitwombat commented on GitHub (Aug 31, 2017):

By the way, feel free to move this discussion to its own issue.

@bitwombat commented on GitHub (Aug 31, 2017): By the way, feel free to move this discussion to its own issue.
Author
Owner

@jelomada commented on GitHub (Sep 4, 2017):

Ok, you' re right. There is no mistake but for me it's really confusing. I've created new issue and I've tried to explain it better.
Maybe there is a way to put it more clearly.
https://github.com/doctrine/doctrine2/issues/6686

@jelomada commented on GitHub (Sep 4, 2017): Ok, you' re right. There is no mistake but for me it's really confusing. I've created new issue and I've tried to explain it better. Maybe there is a way to put it more clearly. https://github.com/doctrine/doctrine2/issues/6686
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5545