[PR #10449] Failing test: Illegal to-many association on MappedSuperclass not rejected #12373

New Issue

admin · 2026-01-22T16:13:51+01:00

admin commented

2026-01-22 16:13:51 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/10449

State: closed
Merged: No

Closing since this is no longer an error condition we need to check for.

#10473 relaxed the runtime check that mapped superclasses must not use one-to-many associations. It turned the check the other way round, so that no mapped superclass may be used as the targetEntity of an association. (In addition, #10554 also made it a "lazy" (non-runtime) check in the schema validator.)

This test case demonstrates a situation where an invalid to-many association on a mapped superclass is not being detected.

Since at least the annotations and attribute drivers currently skip non-private properties from mapped superclasses (see #10417), the ClassMetadataFactory is not even aware of the association on the mapped superclass and so cannot reject it.

IMHO, we should bail out as soon as we detect this on the mapped superclass. I don't see how we could proceed at that time and try to rescue/fixup the situation afterwards.

In addition to that, maybe an association with a target that is a mapped superclass should be rejected in its own right?

More details on what happens down the road, just for the sake of completeness:

When the mapping driver processes the entity class with the inherited association, PHP reflection will report the association property. Since the association was not reported for the mapped superclass, the driver thinks (see #10417) this is a "new" (non-inherited) field and reports to the ClassMetadataFactory.

The association will show up as being from GH10449Entity to GH10449ToManyAssociationTarget. On GH10449ToManyAssociationTarget, it will refer back to GH10449MappedSuperclass.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10449 **State:** closed **Merged:** No --- **Closing** since this is no longer an error condition we need to check for. #10473 relaxed the runtime check that mapped superclasses must not use one-to-many associations. It turned the check the other way round, so that no mapped superclass may be used as the targetEntity of an association. (In addition, #10554 also made it a "lazy" (non-runtime) check in the schema validator.) <hr> This test case demonstrates a situation where an invalid to-many association on a mapped superclass is not being detected. Since at least the annotations and attribute drivers currently skip non-private properties from mapped superclasses (see #10417), the `ClassMetadataFactory` is not even aware of the association on the mapped superclass and so cannot reject it. IMHO, we should bail out as soon as we detect this on the mapped superclass. I don't see how we could proceed at that time and try to rescue/fixup the situation afterwards. In addition to that, maybe an association with a `target` that is a mapped superclass should be rejected in its own right? More details on what happens down the road, just for the sake of completeness: When the mapping driver processes the entity class with the inherited association, PHP reflection will report the association property. Since the association was not reported for the mapped superclass, the driver thinks (see #10417) this is a "new" (non-inherited) field and reports to the `ClassMetadataFactory`. The association will show up as being from `GH10449Entity` to `GH10449ToManyAssociationTarget`. On `GH10449ToManyAssociationTarget`, it will refer back to `GH10449MappedSuperclass`.

admin added the pull-request label 2026-01-22 16:13:51 +01:00

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#12373