Jira issue originally created by user weaverryan:
This is another developer experience situation. Here is the flow:
I setup the owning side of a relationship (let's use ManyToMany, the hardest one for this)
Later, I decide to setup the inverse side of the relationship. When I do this, I of course add the mappedBy attribute so that it points to the exact property/relationship we're dealing with
Then, I also need to go back to the owning side and add inversedBy.
Why is step 3 (inversedBy) needed? Isn't this redundant information, since the mappedBy fully maps out that these 2 associations form different sides of the same relationship? I would love to remove this, I hate explaining to people starting with relationships to now go back to the main entity to add this key. It feels like duplication, which I think people sense.
Of course, I very well may be wrong and it may be needed :).
Comment created by @ocramius:
I'd suggest doing the opposite: dropping mappedBy.
I'm not sure why JPA introduced this sort of bidirectional mapping, but for practical purposes, it makes it possible for us to load metadata for associations on both sides of the associations. Without having both mappedBy and inversedBy we'd be forced to scan through all existing mappings to find which pieces of the jigsaw fit together.
I don't think we have a good solution for this except for a "build mappings" step that warms up a cache, and that's a very radical architectural change that we can only introduce in 3.x
Comment created by Nek:
Hi, please excuse me if what I say is wrong and do not hesitate to correct me, it's my first immertion in Doctrine code :) .
So I checked a little bit the situation in the code. I don't see the problem dropping inversedBy. It's easier understandable for the final user.
In facts right now the ManyToMany work very well with only mappedBy options so the invertedBy is clearly a duplicated information.
The problem for the implementation of this feature is that the ownerSide is decided by a single method for every mappings, so she's quite complexe. So the method decide only on using mappedBy and invertedBy. This behavior should be modifiable without too much troubles.
But another problem here is that should be discuss is that it's a big BC Break.