Initialize the Input DTO For Partial Update in 2.7 and 3.0

[RobinHoutevelts]

(Wasn't aware of the discussions thing. This is great!)

Currently there is an entire documentation section dedicated on how to handle partial updates with a PATCH request.

It seems this is no longer documented for the upcoming 2.7 and 3.0.

It has been raised in #4613 (comment) but seeing as it isn't a bug I thought it was more appropriate to ask here.

[soyuka]

Exists here: https://api-platform.com/docs/main/core/dto/

[RobinHoutevelts]

@soyuka I must be missing something. I don't see anything related to partial updates.

[soyuka]

There's not much to say it will work regarding what method you use. If you need the object to update inspect the context.

[bohanyang]

@soyuka Sorry but I still have no idea how to partial update with a DTO in the new version.

If you need the object to update inspect the context.

What we're going to do is to "populate" the DTO with existing entity data (simply "Entity to DTO conversion").
This should happen in the deserialize stage, which is before the write stage calling state processors.

Entity -> (initialize) -> DTO -> (populate patch request data by denormalizer) -> Patched DTO for state processor

Thus, rather than "inspecting the context for the object to update", we need to "setting an object to populate" for the denormalizer.

Without something like the DataTransformerInitializerInterface's initialize method, the most straightforward way to do this is creating a custom denormalizer, which seems overcomplicated.

Of course it's possible to do this in the state processor:

$entityToPopulate->optionalField = $someDto->optionalField;

$someDto->optionalField may be null since user is unsetting it OR expecting the field to keep its value.
But we can't get that information after the DTO has been deserialized from the user patch request array.

[bohanyang]

After some investigation, I've come up with an idea to solve this by decorating the SerializerContextBuilder. Here's the example, which leverages Symfony DI's tagged locator feature to find out which initializer supports an input class.

Code: https://github.com/bohanyang/api-platform-3-dto-initializer/blob/master/src/ApiPlatform/SerializerInitializerContextBuilder.php

Behavior examples

Keep existing value

Request

{
}

Response

{
  "id": "2",
  "title": "Hello World: 2",
  "content": "This is my first blog post: 2",
  "publishedAt": "2022-09-16T09:03:09+00:00",
  "author": "Kévin Dunglas: 2"
}

Update Field

Request

{
  "author": "Author is updated"
}

Response

{
  "id": "2",
  "title": "Hello World: 2",
  "content": "This is my first blog post: 2",
  "publishedAt": "2022-09-16T09:01:47+00:00",
  "author": "Author is updated"
}

Unset Field

Request

{
  "author": null
}

Response

{
  "id": "2",
  "title": "Hello World: 2",
  "content": "This is my first blog post: 2",
  "publishedAt": "2022-09-16T09:02:38+00:00"
}

It's somewhat hacky but works. I had to override the data attribute to null in the request to bypass this block that overrides the object_to_populate context field. The data attribute will later be set with our deserialized & patched DTO so things should work.

core/src/Symfony/EventListener/DeserializeListener.php

Lines 71 to 79 in 205f59f

	$data = $request->attributes->get('data');
	if (null !== $data) {
	$context[AbstractNormalizer::OBJECT_TO_POPULATE] = $data;
	}
	$request->attributes->set(
	'data',
	$this->serializer->deserialize($request->getContent(), $context['resource_class'], $format, $context)
	);

[TheKassaK]

Any news ?
Is there an equivalent for DataTransformerInitializerInterface in 2.7/3 ?

[jelovac]

In addition to the above when we use custom input DTO with PUT operation in the $context which is passed to the State Processor we will have 'data' which is an instance of DTO and 'previous_data' which is a clone of the actual loaded resource.

Since previous data is a cloned resource object it means that it is not managed by Doctrine's Unit Of Work. Any modification on that resource will cause INSERT operation instead of UPDATE in doctrine.

So this prevent us to do the following:

// Custom State Processor
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []) {
    $inputDto = $context['data'];
    $existingObjectForUpdate = $context['previous_data'];

    $existingObjectForUpdate->someField = $inputDto->someField;

    $this->entityManager->persist($existingObjectForUpdate);
    $this->entityManager->flush();
}

Instead we need to do the following:

// Custom State Processor
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []) {
    $inputDto = $context['data'];
    $existingObjectForUpdate = $this->someEntitySerivce->load($uriVariables['id']);

    $existingObjectForUpdate->someField = $inputDto->someField;

    $this->entityManager->persist($existingObjectForUpdate);
    $this->entityManager->flush();
}

[mbrodala]

@jelovac Thanks a lot for this hint (and the research you very likely put into this). This did also break our migration of a data transformer to a processor. (The purpose here was also to populate an actual API resource from data of a custom input with custom validation.)

Too bad that data transformers are deprecated (without apparent reason) and no equal replacement in place ...

[soyuka]

IMHO the way we implemented DTOs is wrong. I want to deprecate input and output for serialization and it'll be used for documentation only. The best way for doing this is to declare the operation on your input and specify the output object for documentation purpose:

#[Post('/foo', output: SomethingElse::class)]
class MyInput {}

Then in a provider / processor do whatever you want.

[mbrodala]

That would indeed make things clearer / less obscure.