[PR #12174] Do not eagerly set metadata from ResolveTargetEntityListener #13543

New Issue

admin · 2026-01-22T16:17:27+01:00

admin commented

2026-01-22 16:17:27 +01:00

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

State: closed
Merged: Yes

When using the ResolveTargetEntityListener to substitute targetEntities in association mappings, do not eagerly put the resolved (target) entity into the class metadata cache under the class name of the original entity.

Motivation

I have a library that wants to distribute a MappedSuperclass as the base for some functionality. It will be necessary that clients using the library will extend the MappedSuperclass to fill in some blanks, creating the first real #[Entity] instance of it.

This client-provided entity will be the primary means of working with the class. Thus, I was following the note in the documentation and using the ResolveTargetEntityListener to declare that whenever an association refers to that mapped superclass, the particular entity class shall be used instead.

One-To-Many associations are not generally possible on a mapped superclass, since they require the "many" side to hold the foreign key.
It is, however, possible to use the ResolveTargetEntityListener to replace references to a mapped superclass with an entity class at runtime. As long as there is only one entity subclass inheriting from the mapped superclass and all references to the mapped superclass are resolved to that entity class at runtime, the mapped superclass can use One-To-Many associations and be named as the targetEntity on the owning sides.

Changes made

The ResolveTargetEntityListener primarily does what its name suggests: For newly loaded class metadata, it inspects all associations declared and replaces the targetEntity with new (resolved) values.

But additionally, when a loaded class is the target of such a resolution, it would also put the class metadata into the cache under the name of the original entity.

I think that extra step is wrong, and this PR removes it. It had the side effect that when other classes extending the MappedSuperclass were loaded after the resolve target class has been seen for the first time, the metadata for those classes would not inherit from the mapped superclass anymore, but from the target entity class instead. In my real-life use case, this causes weird mapping errors down the road; as of ^3.0, it would throw a mapping exception asking to configure inheritance mapping. But note that there would be no inheritance between the entity classes at all.

More background

The documentation describes the use of ResolveTargetEntityListener with an interface that is resolved to an entity class. For an interface, adding the extra metadata does not make a difference, since it never interferes with actual entity or mapped superclasses.

The initial idea of adding a copy of the entity class metadata under the interface name came from commit
9c7f3f2747 in #385. The goal was to make it possible to also find entities by interface names, like so:

$em->find('Foo\BarBundle\Entity\PersonInterface', 1);

It then turned out that this only worked when the resolution had already been applied. So, the new onClassMetadataNotFound event was added and the resolution map would be checked in that case as well (#1181). The inital code stayed in place, possibly giving a small performance gain.

**Original Pull Request:** https://github.com/doctrine/orm/pull/12174 **State:** closed **Merged:** Yes --- When using the `ResolveTargetEntityListener` to substitute `targetEntities` in association mappings, do not eagerly put the resolved (target) entity into the class metadata cache under the class name of the original entity. #### Motivation I have a library that wants to distribute a MappedSuperclass as the base for some functionality. It will be necessary that clients using the library will extend the MappedSuperclass to fill in some blanks, creating the first real `#[Entity]` instance of it. This client-provided entity will be the primary means of working with the class. Thus, I was following the [note in the documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/3.5/reference/inheritance-mapping.html#mapped-superclasses:~:text=It%20is%2C%20however) and using the `ResolveTargetEntityListener` to declare that whenever an association refers to that mapped superclass, the particular entity class shall be used instead. > One-To-Many associations are not generally possible on a mapped superclass, since they require the "many" side to hold the foreign key. > It is, however, possible to use the [ResolveTargetEntityListener](https://www.doctrine-project.org/projects/doctrine-orm/en/3.5/cookbook/resolve-target-entity-listener.html) to replace references to a mapped superclass with an entity class at runtime. As long as there is only one entity subclass inheriting from the mapped superclass and all references to the mapped superclass are resolved to that entity class at runtime, the mapped superclass can use One-To-Many associations and be named as the targetEntity on the owning sides. #### Changes made The `ResolveTargetEntityListener` primarily does what its name suggests: For newly loaded class metadata, it inspects all associations declared and replaces the `targetEntity` with new (resolved) values. But additionally, when a loaded class is the target of such a resolution, it would also put the class metadata into the cache under the name of the original entity. I think that extra step is wrong, and this PR removes it. It had the side effect that when other classes extending the MappedSuperclass were loaded _after_ the resolve target class has been seen for the first time, the metadata for those classes would not inherit from the mapped superclass anymore, but from the target entity class instead. In my real-life use case, this causes weird mapping errors down the road; as of ^3.0, it would throw a mapping exception asking to configure inheritance mapping. But note that there would be no inheritance between the entity classes at all. #### More background The documentation [describes the use of `ResolveTargetEntityListener`](https://www.doctrine-project.org/projects/doctrine-orm/en/3.5/cookbook/resolve-target-entity-listener.html) with an interface that is resolved to an entity class. For an interface, adding the extra metadata does not make a difference, since it never interferes with actual entity or mapped superclasses. The initial idea of adding a copy of the entity class metadata under the interface name came from commit 9c7f3f27471b204a23a937578496388747ffb5d8 in #385. The goal was to make it possible to also find entities by interface names, like so: ``` $em->find('Foo\BarBundle\Entity\PersonInterface', 1); ``` It then [turned out that this only worked when the resolution had already been applied](https://github.com/doctrine/orm/pull/385#issuecomment-6658893). So, the new `onClassMetadataNotFound` event was added and the resolution map would be checked in that case as well (#1181). The inital code stayed in place, possibly giving a small performance gain.

admin added the pull-request label 2026-01-22 16:17:27 +01:00

admin closed this issue

2026-01-22 16:17:28 +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#13543

[PR #12174] Do not eagerly set metadata from ResolveTargetEntityListener #13543

Motivation

Changes made

More background

[PR #12174] Do not eagerly set metadata from `ResolveTargetEntityListener` #13543