feat(symfony): object mapper with state options #6801
Conversation
soyuka
force-pushed
the
feat/automapper
branch
from
3a5efe5 to
6e954d5
Compare
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
There was a problem hiding this comment.
I think these provider and processor are Doctrine-specific. They should be moved to the Doctrine namespace and we can consider injecting the ObjectManager of ORM or ODM to retrieve the attached object.
Unless the new symfony/mapper component is able to use a factory to create the Entity class from the DTO. It would use the Id field of the DTO to retreive the attached entity from the entity manager.
| "repositories": [ | ||
| { "type": "path", "url": "../symfony/src/Symfony/Component/ObjectMapper" }, | ||
| { "type": "path", "url": "../symfony/src/Symfony/Bundle/FrameworkBundle" } | ||
| ], |
There was a problem hiding this comment.
If that can help, I use this script to link external directories in my project vendors: https://gist.github.com/GromNaN/020dd50fc3ed71d31ebc548bb75845e7
There was a problem hiding this comment.
I built https://github.com/soyuka/pmu for that now :p
| return $this->decorated->process($data, $operation, $uriVariables, $context); | ||
| } | ||
|
|
||
| return $this->objectMapper->map($this->decorated->process($this->objectMapper->map($data), $operation, $uriVariables, $context)); |
There was a problem hiding this comment.
In PATCH and DELETE operations, you must map into the entity attached to the EntityManager when retrieved in the provider.
Otherwise the decorated doctrine processor will try to persist a new object (and maybe fail on duplicate primary key), or skip removing the non-persisted entity.
| return $data; | ||
| } | ||
|
|
||
| $entityClass = $operation->getClass(); |
There was a problem hiding this comment.
The DenormalizeProvider already create an instance of the operation class. Mapping into the same target class as the source class doesn't seem a valid use case to me. Making this provider useful only with Doctrine.
There was a problem hiding this comment.
The denormalizer provider is only called on write operations. but indeed they should be doctrine-oriented it would make more sense
Still a few things left to be done but this is a first approach. This makes API Platform compatible with the Object Mapper component: symfony/symfony#51741