`skip_uninitialized_values` not working ?

[TheoD02]

I am trying to map a payload for a PATCH endpoint and would like to configure it so that:

• If a property is uninitialized, it is skipped during the update.
• If a property is explicitly set to null, it should update the field to null (if the field is nullable).

However, the current behavior of skip_uninitialized_values is not working.

I have also tried using skip_null_values, but this is problematic because it skips both uninitialized and null values. In cases where a field is nullable (e.g., birthdate), this prevents setting a nullable field to null during a PATCH operation.

Example:

Here’s a basic example of my User entity:

class User
{
    private string $name;

    private ?\DateTimeInterface $birthdate = null; // Nullable
}

In a PATCH request, I would like the following behavior:

• If birthdate is not provided in the payload, it should remain unchanged.
• If birthdate is explicitly set to null in the payload, it should be updated to null in the entity.

Here’s what the request payload might look like:

{
    "name": "John Doe",
    "birthdate": null
}

Expected Behavior:

• Properties that are uninitialized (e.g., not provided in the payload) should be skipped in the update.
• Nullable properties (like birthdate) should be updated to null if explicitly set to null.

Current Behavior:

• skip_uninitialized_values does not skip uninitialized properties as expected.
• skip_null_values skips both uninitialized and null values, making it impossible to set a nullable field to null in a PATCH request.

Steps to Reproduce:

1. Create a User entity with a nullable field (e.g., birthdate).
2. Attempt to perform a PATCH request where some fields are not provided and others are explicitly set to null.
3. Observe that uninitialized fields are not skipped correctly, or nullable fields can't be updated to null.

Questions:

• Is there a way to achieve this behavior using the current options?

[MrMeshok]

class User
{
    private string $name;

    private ?\DateTimeInterface $birthdate = null; // Nullable
}

When you type property with default value it already initialized on creation, so if you just remove = null it should work as expected.

[TheoD02]

class User
{
    private string $name;

    private ?\DateTimeInterface $birthdate = null; // Nullable
}

When you type property with default value it already initialized on creation, so if you just remove = null it should work as expected.

Thanks for answer :)

Yes for that case, but in case you only want to update partially a resource, if birthdate is present, but name is not. An error will occur because mapper will attempt to map name but is uninitialized

[MrMeshok]

Can you provide full example with configuration for AutoMapper? I am testing with AutoMapper::create() without any configuration and have no errors

[TheoD02]

Check here: https://phpsandbox.io/n/w5wwq#public/index.php

If I want to only update partially a resource, by setting only birthdate or lastName that will not work because other properties are uninitialized.

If birthdate is set to null or date, it should update value, otherwise it should not, for example

[MrMeshok]

I see now, for me, it's working because I was mapping from array/stdClass. When I was working with PATCH requests, I did this kind of mapping by hand. Yeah, it's kinda ugly with several if statements, but you can control all the logic

[TheoD02]

I see now, for me, it's working because I was mapping from array/stdClass. When I was working with PATCH requests, I did this kind of mapping by hand. Yeah, it's kinda ugly with several if statements, but you can control all the logic

OK, thanks for your time, make it by hand need some effort that is not really needed in my case ^^

I think the preferable solution will be to split skip_uninitialized_values and skip_null_values to support both approach

[joelwurtz]

Indeed we don't support skip_uninitialized_values yet, would be a nice addition, will add this to roadmap

[Korbeil]

I started working on this mater and got something working, I need to fix some tests but the feature is there if you wanna take a look at it: https://github.com/jolicode/automapper/pull/200

[jg-development]

+1 ... can confirm this is currently not working. are u trying to implement this feature?

[damienalexandre]

@jg-development Feedback would be appreciated on the related PR: #200

Would you have the opportunity to test it by any chance?

Thanks

[jg-development]

can do... give me a day or two

[jg-development]

sry for the delayed answer I was kind of sick. could not really check this out. is this still an issue to check?

[Korbeil]

@jg-development no worries, we did fixed the issue and released it, you can test it with the last version of AutoMapper :)