DDC-3206: Possible to remove inversedBy (use only mappedBy)? #3971

New Issue

admin · 2026-01-22T14:32:34+01:00

admin commented

2026-01-22 14:32:34 +01:00

Originally created by @doctrinebot on GitHub (Jul 5, 2014).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user weaverryan:

Hi guys!

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 :).

Thanks!

Originally created by @doctrinebot on GitHub (Jul 5, 2014). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user weaverryan: Hi guys! This is another developer experience situation. Here is the flow: 1. I setup the owning side of a relationship (let's use ManyToMany, the hardest one for this) 2. 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 3. 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 :). Thanks!

admin added the Improvement label 2026-01-22 14:32:34 +01:00

admin commented

2026-01-22 14:32:35 +01:00

@doctrinebot commented on GitHub (Jul 6, 2014):

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

@doctrinebot commented on GitHub (Jul 6, 2014): 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

admin commented

2026-01-22 14:32:36 +01:00

@doctrinebot commented on GitHub (Jul 7, 2014):

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.

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L1353

But another problem here is that should be discuss is that it's a big BC Break.

@doctrinebot commented on GitHub (Jul 7, 2014): 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. https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L1353 But another problem here is that should be discuss is that it's a big BC Break.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3971