Invalid Bidirectional Association Mapping with Mapped Superclass in Class Hierarchy #6933

New Issue

admin · 2026-01-22T15:41:40+01:00

admin commented

2026-01-22 15:41:40 +01:00

Originally created by @bobdercole on GitHub (Feb 15, 2022).

Bug Report

Q	A
BC Break	no
Version	2.11.1

Summary

I receive a mapping exception after defining an inverse-side association on an abstract entity. A mapped superclass extends the abstract entity. A concrete entity extends the mapped superclass.

Current behavior

ClassMetadataFactory is currently throwing an exception if there is an inverse-side association on a mapped superclass.

e8e61cbbd5/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php (L381)

This is correct, as stated in the documentation. However, I believe this limitation should be imposed only if the association is on the mapped superclass itself.

How to reproduce

Define an abstract entity (A).
Define a mapped superclass (B) extends A.
Define a concrete entity (C) extends B.
Define another entity (D) that has a many-to-one relationship with A.

I will follow-up with a failing test case.

Expected behavior

I think the above mapping should be valid since the association is not defined directly on the mapped superclass.

Originally created by @bobdercole on GitHub (Feb 15, 2022). ### Bug Report  | Q | A |------------ | ------ | BC Break | no | Version | 2.11.1 #### Summary  I receive a mapping exception after defining an inverse-side association on an abstract entity. A mapped superclass extends the abstract entity. A concrete entity extends the mapped superclass. #### Current behavior  ClassMetadataFactory is currently throwing an exception if there is an inverse-side association on a mapped superclass. https://github.com/doctrine/orm/blob/e8e61cbbd56566c27bc5f766ac017d7921eb5577/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L381 This is correct, as stated in the [documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/inheritance-mapping.html#mapped-superclasses). However, I believe this limitation should be imposed only if the association is on the mapped superclass itself. #### How to reproduce  - Define an abstract entity (A). - Define a mapped superclass (B) extends A. - Define a concrete entity (C) extends B. - Define another entity (D) that has a many-to-one relationship with A. I will follow-up with a failing test case. #### Expected behavior  I think the above mapping should be valid since the association is not defined directly on the mapped superclass.

admin closed this issue

2026-01-22 15:41:40 +01:00

admin commented

2026-01-22 15:41:41 +01:00

@bobdercole commented on GitHub (Feb 15, 2022):

Here is my failing test case: #9517.

My proposed fix is to add a condition to ClassMetadataFactory to only throw the exception if the association is directly on the mapped superclass. Maybe something like this?

if ($mapping['type'] & ClassMetadata::TO_MANY && ! $mapping['isOwningSide'] && $parentClass->name === $mapping['sourceEntity']) {
    throw MappingException::illegalToManyAssociationOnMappedSuperclass($parentClass->name, $field);
}

@bobdercole commented on GitHub (Feb 15, 2022): Here is my failing test case: #9517. My proposed fix is to add a condition to [ClassMetadataFactory](https://github.com/doctrine/orm/blob/e8e61cbbd56566c27bc5f766ac017d7921eb5577/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L381) to only throw the exception if the association is directly on the mapped superclass. Maybe something like this? ```php if ($mapping['type'] & ClassMetadata::TO_MANY && ! $mapping['isOwningSide'] && $parentClass->name === $mapping['sourceEntity']) { throw MappingException::illegalToManyAssociationOnMappedSuperclass($parentClass->name, $field); } ```

admin commented

2026-01-22 15:41:42 +01:00

@mpdude commented on GitHub (Feb 21, 2022):

Related to #8415 (as per #9517).

@mpdude commented on GitHub (Feb 21, 2022): Related to #8415 (as per #9517).

admin commented

2026-01-22 15:41:42 +01:00

@mpdude commented on GitHub (Jan 23, 2023):

Please check if this is already fixed in the current 2.14.x branch

@mpdude commented on GitHub (Jan 23, 2023): Please check if this is already fixed in the current 2.14.x branch

admin commented

2026-01-22 15:41:42 +01:00

@mpdude commented on GitHub (Jan 23, 2023):

You might also want to subscribe to #10398

@mpdude commented on GitHub (Jan 23, 2023): You might also want to subscribe to #10398

admin commented

2026-01-22 15:41:43 +01:00

@bobdercole commented on GitHub (Jan 28, 2023):

Please check if this is already fixed in the current 2.14.x branch

Yes! It works now. Thank you for all the work you've done to resolve it!

I suppose we should keep this open until the regression test PR is merged.

@bobdercole commented on GitHub (Jan 28, 2023): > Please check if this is already fixed in the current 2.14.x branch Yes! It works now. Thank you for all the work you've done to resolve it! I suppose we should keep this open until the regression test PR is merged.

admin commented

2026-01-22 15:41:43 +01:00

@mpdude commented on GitHub (Jan 28, 2023):

@greg0ire maybe a low hanging fruit:

Merge #10453 and then close the issues and PRs linked from it

@mpdude commented on GitHub (Jan 28, 2023): @greg0ire maybe a low hanging fruit: Merge #10453 and then close the issues and PRs linked from it

admin referenced this issue

2026-01-22 16:07:24 +01:00

[PR #7276] Add UPGRADE note for EntityRepository::count() #10400

Sign in to join this conversation.