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

New Issue

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

admin commented

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

📋 Pull Request Information

Original PR: https://github.com/doctrine/orm/pull/12174
Author: @mpdude
Created: 9/19/2025
Status: ✅ Merged
Merged: 10/15/2025
Merged by: @greg0ire

Base: 2.20.x ← Head: resolve-target-entity-listener-no-eager-metadata

📝 Commits (2)

8c6ae83 Do not eagerly set metadata from ResolveTargetEntityListener
859bb25 Rename test method for clarity

📊 Changes

3 files changed (+96 additions, -12 deletions)

View changed files

📝 phpstan-baseline.neon (+0 -6)
📝 src/Tools/ResolveTargetEntityListener.php (+0 -6)
➕ tests/Tests/ORM/Functional/Ticket/GH12174Test.php (+96 -0)

📄 Description

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.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/doctrine/orm/pull/12174 **Author:** [@mpdude](https://github.com/mpdude) **Created:** 9/19/2025 **Status:** ✅ Merged **Merged:** 10/15/2025 **Merged by:** [@greg0ire](https://github.com/greg0ire) **Base:** `2.20.x` ← **Head:** `resolve-target-entity-listener-no-eager-metadata` --- ### 📝 Commits (2) - [`8c6ae83`](https://github.com/doctrine/orm/commit/8c6ae837bad53abfd2374388d07439d628d8785a) Do not eagerly set metadata from ResolveTargetEntityListener - [`859bb25`](https://github.com/doctrine/orm/commit/859bb25ce8b3def5d1647c59db60969866b26662) Rename test method for clarity ### 📊 Changes **3 files changed** (+96 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `phpstan-baseline.neon` (+0 -6) 📝 `src/Tools/ResolveTargetEntityListener.php` (+0 -6) ➕ `tests/Tests/ORM/Functional/Ticket/GH12174Test.php` (+96 -0) </details> ### 📄 Description 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. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

admin added the pull-request label 2026-01-22 16:17:26 +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#13541

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