[PR #10554] Make "targetEntity must not be a mapped superclass" a lazy check #12449

New Issue

admin · 2026-01-22T16:14:05+01:00

admin commented

2026-01-22 16:14:05 +01:00

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

State: closed
Merged: Yes

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

To find out whether a class is a mapped superclass, the \Doctrine\ORM\Mapping\ClassMetadataFactory::peekIfIsMappedSuperclass method was used, which is directly using the mapping driver.

#10552 reports a case where mapping configuration is not collected through the driver alone, but also a metadata listener is contributing relevant information. Updating metadata with a listener is currently not supported by the check in that method.

Also, https://github.com/doctrine/orm/pull/10473#issuecomment-1450048660 has a mapping configuration that cannot be loaded in the improvised way that \Doctrine\ORM\Mapping\ClassMetadataFactory::peekIfIsMappedSuperclass employs.

As I explained in https://github.com/doctrine/orm/issues/10552#issuecomment-1450794332, we cannot use the full ClassMetadataFactory itself to obtain information about the targetEntity while we're performing runtime validation for another class currently being loaded.

So, I don't see any other way than to make this check a non-runtime (offline?) check in the SchemaValidator. There, we can first completely load metadata for all classes and then inspect it.

Many fixes to the test models that were made in #10473 can be reverted, since these files are no longer scrutinized at runtime, and we probably don't care about the extra validation checks that much.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10554 **State:** closed **Merged:** Yes --- #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. To find out whether a class is a mapped superclass, the `\Doctrine\ORM\Mapping\ClassMetadataFactory::peekIfIsMappedSuperclass` method was used, which is directly using the mapping driver. #10552 reports a case where mapping configuration is not collected through the driver alone, but also a metadata listener is contributing relevant information. Updating metadata with a listener is currently not supported by the check in that method. Also, https://github.com/doctrine/orm/pull/10473#issuecomment-1450048660 has a mapping configuration that cannot be loaded in the improvised way that `\Doctrine\ORM\Mapping\ClassMetadataFactory::peekIfIsMappedSuperclass` employs. As I explained in https://github.com/doctrine/orm/issues/10552#issuecomment-1450794332, we cannot use the full ClassMetadataFactory itself to obtain information about the `targetEntity` while we're performing runtime validation for another class currently being loaded. So, I don't see any other way than to make this check a non-runtime (offline?) check in the `SchemaValidator`. There, we can first completely load metadata for all classes and then inspect it. Many fixes to the test models that were made in #10473 can be reverted, since these files are no longer scrutinized at runtime, and we probably don't care about the extra validation checks that much.

admin added the pull-request label 2026-01-22 16:14:05 +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#12449