You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
When updating a resource while using a DTO as an input, (and not using the DTO as the direct resource), Serializer does not deserialize the ID onto the DTO.
How to reproduce
Here is a sample situation with an Entity, an Input DTO, and a Processor to reveal missing ID.
// The Entity class.
#[ApiResource(
operations: [
newPatch(
...
uriTemplate: '/api/entity/{id}',
input: EntityInput::class,
processor: EntityProcessor::class
),
],
)]
classEntity
{
#[ORM\Id]
#[ORM\Column(type: 'uuid', unique: true)]
#[ApiProperty(identifier: true)]
privateUuid$id;
...
}
// The DTO class.classEntityInput
{
public ?Uuid$id = null;
// Whatever data to be sent.publicstring$date;
publicarray$information;
...
}
// The API Request.
->PATCH({
'/api/entity/{123456}',
{
date: 01-01-2024
information: [
'important',
'data',
]
}
})
// The Processor.
class EntityProcessor
{
/** * @param EntityInput $data */
public function process(mixed $data, Operation$operation, array $uriVariables = [], array $context = []) {
\assert $data instanceof EntityInput; // True !$data->getId(); // null ??
}
}
Here, I was expecting 123456 to be id.
I know the ID is available. If you hook into the deserializer, $context[ObjectNormalizer::OBJECT_TO_POPULATE] contains the Original Entity to be updated (not at the processor level however). and the identifier is extracted correctly every time. This works as expected when the DTO is the Resource itself. Shouldnt it work the other way around?
Possible Solution
SO im guessing its one of 2 things.
IDs are only deserialized onto DTOs if the DTO is the ApiResource itself
If so, I think this should be documented and the DTO example in documentation should stop using input:
(Its a bug) IDs should be deserialized, but its not working when used as input: class.
I mis-attributed by entity classes altogether. everything should work fine.
The text was updated successfully, but these errors were encountered:
API Platform version(s) affected: 3.2.x ?+
Description
When updating a resource while using a DTO as an input, (and not using the DTO as the direct resource), Serializer does not deserialize the ID onto the DTO.
How to reproduce
Here is a sample situation with an Entity, an Input DTO, and a Processor to reveal missing ID.
Here, I was expecting
123456
to beid
.I know the ID is available. If you hook into the deserializer, $context[ObjectNormalizer::OBJECT_TO_POPULATE] contains the Original Entity to be updated (not at the processor level however). and the identifier is extracted correctly every time. This works as expected when the DTO is the Resource itself. Shouldnt it work the other way around?
Possible Solution
SO im guessing its one of 2 things.
If so, I think this should be documented and the DTO example in documentation should stop using
input:
input:
class.The text was updated successfully, but these errors were encountered: