set metadata for interface to be able to fetch entites by interface name #385
Conversation
| @@ -66,6 +66,12 @@ public function loadClassMetadata(LoadClassMetadataEventArgs $args) | |||
| $this->remapAssociation($cm, $mapping); | |||
| } | |||
| } | |||
|
|
|||
| foreach($this->resolveTargetEntities as $interface => $data) { | |||
|
Hm, this only works if the CM for the actual entity is loaded before requesting the CM for the interface (see added failing test)... Any suggestions? |
|
hm this would be very cool, but i dont see a way to get it working. |
|
@beberlei perhaps a new preLoadClassMetadata event can be introduced. The ResolveTargetEntityListener could then listen into this event and make sure the original class is loaded, which in turn (if this PR would be merged) would make sure the interface metadata is registered as well |
|
@beberlei I've added a commit which makes it possble. Let me know what you think. |
|
Yes its better, but i fear you have to start over, we merged a huge refactoring in ClassMetadataFactory. But my idea would be to throw an event when a classmetadata could not be found, and then allow to recover from that event. |
| $eventArgs = new \Doctrine\ORM\Event\PreLoadClassMetadataEventArgs($className, $this->em); | ||
| $this->evm->dispatchEvent(Events::preLoadClassMetadata, $eventArgs); | ||
| } | ||
| } |
There was a problem hiding this comment.
@beberlei this place is now in Common. If you want to trigger an event in this place, you will need to add a hook in Common.
There was a problem hiding this comment.
yes i know, thats what i mean with "start over" :-(
but the event should rather be "onClassMetadataNotFound" or something.
|
i am asking myself if the resolve metadata listener features should be in the core of metadata factory. Adding this event would only be for this use-case. I dont see any other use-case for the event. |
|
@beberlei What's your pov on this? Should it be in the core? Hopefully I will have time next week to rewrite the commit (or otherwise apply it to common). |
|
@beberlei I've rebased the branch on to master (and renamed the event as you suggested), but everything still works fine... Can you tell me what needs to change because of the refactoring? |
| * @param \Doctrine\ORM\Mapping\ClassMetadataInfo $classMetadata | ||
| * @param \Doctrine\ORM\EntityManager $em | ||
| */ | ||
| public function __construct($className, EntityManager $em) |
There was a problem hiding this comment.
you should tipehint the first argument if it is really a ClassMetadataInfo
|
@Burgov it looks like you messed the ClassMetadataFactory when rebasing, or you forgot to update your master before rebasing. Because currently, it is not based on the current code |
|
@stof you're right... It helps to rebase onto upstream/master instead of origin/master ^_^ I'll rewrite this PR later on |
| Events::loadClassMetadata, | ||
| Events::onClassMetadataNotFound | ||
| ); | ||
| } | ||
| /** |
|
you should add some tests |
|
Any help on this one please? In the original PR an event was dispatched at a place which has now been refactored to a base class in Doctrine/Common, which doesn't have the event dispatcher. I'm not sure how to resolve this...
|
|
Finally, Could you resolve this? Thanks. |
|
I ported this PR to #1181. Closing here. |
…licate imports (caused by rebase conflicts)
…ssed/cleared
…ewly introduced tests
…nterface-first fetching of metadata (via fallback logic)
…tadataNotFoundEventArgs`
…undEventArgs` from `ManagerEventArgs` instead of generic `EventArgs`
…etadataNotFoundEventArgs` API
…on to new `OnClassMetadataNotFoundEventArgs` API
…ataNotFoundEventArgs` impl
…EventArgs` docblocks as per @deeky666's review
…entities-by-aliased-name Support fetching entities by aliased name
using the new ResolveTargetEntity functionality we noticed we needed another feature:
From the Symfony Bundle defining the interface, we'd like to be able to fetch entities by this very interface name, e.g.:
or
This PR sets metadata for the interface when metadata for a class is loaded that the interface is configured for