Use ResolveTargetEntityListener to remap the discriminatorMap with STI/JTI #6183

New Issue

admin · 2026-01-22T15:28:25+01:00

admin commented

2026-01-22 15:28:25 +01:00

Originally created by @axelvnk on GitHub (Feb 22, 2019).

Feature Request

I ran into an issue past week and couldn't figure out what I was doing wrong. At the company I work at, we've created some bundles for reuse. We use interfaces in the association mapping, so we can extend entities and have the associations within the bundle to be remapped with the concrete classes.

I made the mistake to assume that the ResolveTargetEntityListener would also remap the discriminatorMap for STI/JTI entities. It seemed so evident to me that this would also work. I realise the name of the listener itself says ResolveTargetEntityListener and so it would only resolve the targetEntity properties of the association mappings. I find resolving target entities such a powerful feature, for extensibility in vendor libraries/bundles, that it's a shame I am forced to extend the STI/JTI entity whenever I extend an entity from the discriminatorMap,, because I need to change the discriminatorMap with the new concrete class.

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

I suggest either creating a new listener, ResolveDiscriminatorMapListener or renaming the current listener to something else and add the feature to remap the discriminatorMap.

I wonder what your thoughts are. I'm happy to do this myself and open up a PR if there's interest in such feature.

Originally created by @axelvnk on GitHub (Feb 22, 2019). ### Feature Request I ran into an issue past week and couldn't figure out what I was doing wrong. At the company I work at, we've created some bundles for reuse. We use interfaces in the association mapping, so we can extend entities and have the associations within the bundle to be remapped with the concrete classes. I made the mistake to assume that the ResolveTargetEntityListener would also remap the discriminatorMap for STI/JTI entities. It seemed so evident to me that this would also work. I realise the name of the listener itself says Resolve**TargetEntity**Listener and so it would only resolve the targetEntity properties of the association mappings. I find resolving target entities such a powerful feature, for extensibility in vendor libraries/bundles, that it's a shame I am forced to extend the STI/JTI entity whenever I extend an entity from the discriminatorMap,, because I need to change the discriminatorMap with the new concrete class. | Q | A |------------ | ------ | New Feature | yes | RFC | yes/no | BC Break | yes/no #### Summary I suggest either creating a new listener, ResolveDiscriminatorMapListener or renaming the current listener to something else and add the feature to remap the discriminatorMap. I wonder what your thoughts are. I'm happy to do this myself and open up a PR if there's interest in such feature.

admin added the New Feature Missing Tests Question labels 2026-01-22 15:28:25 +01:00

admin commented

2026-01-22 15:28:27 +01:00

@Ocramius commented on GitHub (Feb 22, 2019):

@axelvnk can you please design a test case highlighting what the current system is doing, vs what you'd want it to do?

I'd expect references to "re-mapped" entities to be replaced also in discriminator maps.

@Ocramius commented on GitHub (Feb 22, 2019): @axelvnk can you please design a test case highlighting what the current system is doing, vs what you'd want it to do? I'd expect references to "re-mapped" entities to be replaced also in discriminator maps.

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