This repository has been archived by the owner on Feb 24, 2023. It is now read-only.
Support using resolve_target_entities
in DoctrineParamConverter
#705
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Doctrine ORM provides a way to use Interfaces e. g. in Association Mappings. Then a config setting named
resolve_target_entities
can be used to supply an Interface-to-Classname mapping. Whenever Doctrine ORM encounters one of the mapped interfaces while loading metadata, it will fall back to the mapped class instead.This PR aims to support this feature in the
DoctrineParamConverter
as well.To go with the example from the above documentation section,
@ParamConverter("...", class="App\Model\InvoiceSubjectInterface")
would pick up the mapping to the concreteApp\Entity\Customer
class and pass an instance of that into the controller.The main challenge is that inside
\Doctrine\Persistence\AbstractManagerRegistry
, thegetManagerForClass()
method only looks at theisTransient()
metadata property to make a quick decision if something is an entity that could be loaded.isTransient()
, however, is alwaysfalse
for interfaces. The target entity resolution only happens inside Doctrines MetadataFactory when actually loading metadata.So, to support this new use case, we cannot use
getManagerForClass()
but need to be a bit more elaborate. But basically, the code now present here is close to the one used insideAbstractManagerRegistry
. In particular, it avoids to fetch Managers (expensive services?) as much as the previous implementation.