Handle PATCH with ObjectMapper

[Cafeine42]

Description
When using Symfony ObjectMapper in a PATCH operation, properties that are not sent in the request payload appear to be overwritten (set to null) instead of being left unchanged. This makes it difficult to use ObjectMapper for partial updates.

Problem
ObjectMapper does not seem to distinguish between:

• a property that is explicitly provided as null in the input DTO, and
• a property that is not initialized / not provided at all in the PATCH payload.

As a result, non-sent properties are not ignored during mapping and may unintentionally nullify existing entity values.

Requested Documentation or Feature
It would be helpful to clarify or support a recommended way to use ObjectMapper to implement an API PATCH operation, for example:

• an option or pattern to ignore non-initialized DTO properties during mapping, or
• clear guidance on whether input DTO properties are expected to be nullable for PATCH, and how partial updates should be handled safely.

A concrete example of a PATCH operation using ObjectMapper (DTO → existing entity) that demonstrates proper partial update behavior would greatly help.

See Cafeine42/api-platform-sandbox@27ee5f1 for reproducer.

Additional Context / Current Workaround

I implemented a custom condition:

class IsNotNullCondition implements ConditionCallableInterface
{
    public function __invoke(mixed $value, object $source, ?object $target): bool
    {
        return null !== $value;
    }
}

and used it with:

#[Map(if: IsNotNullCondition::class)]

to prevent ObjectMapper from overwriting properties when they are not provided.

Limitation of This Approach

This workaround has a major drawback:
it completely prevents using PATCH to explicitly set a property to null.

To make this work, it requires:

• setting null as the default value for all DTO properties, and
• adapting validation constraints to ignore null values everywhere.

This makes PATCH handling significantly more complex and error-prone, and it blurs the semantic difference between:

• “field not provided”
• “field explicitly set to null”.

[soyuka]

Interesting thanks! Maybe that this needs fixing in the ObjectMapper itself.

Maybe relates to #7605

[soyuka]

The issue is that your DTO has default null values:

#[Map(target: PatchTestEntity::class)]
final class PatchTestInput
{
    public ?string $name;
    public ?string $description;
    public ?string $status;
}

This allows properties to be "uninitialized" and will work properly according to my tests.

[Cafeine42]

@soyuka

Thanks, I hadn’t noticed this behavior when the property is non-nullable.

For properties that can be nullable, it seems reasonable to support this in PATCH by detecting whether the value has been explicitly initialized ? making it possible to distinguish “not provided” from an explicit null with ObjectMapper ?

I have updated my example.

I’ll experiment with using symfony/validator to ignore uninitialized properties, since this will be part of my issue.

[Cafeine42]

More intel

And I need to tweak php-cs-fixer adding = null on all nullable properties...

[soyuka]

I don't understand it's the case an uninitialized property is different from null.

[soyuka]

Can you patch my test at soyuka@660c499 and let me know what I did wrong?