Setting API attributes to null for patch operations.
Checklist
- [x] I have looked into the Readme and Examples, and have not found a suitable solution or answer.
- [x] I have looked into the API documentation and have not found a suitable solution or answer.
- [x] I have searched the issues and have not found a suitable solution or answer.
- [x] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- [x] I agree to the terms within the Auth0 Code of Conduct.
Describe the problem you'd like to have solved
I have an issue when trying to perform updates to User objects within the Auth0 API. This may affect any of the APIs where the endpoint expect NULL values to clear the attribute from the updated entity. This is expecially true for PATCH operations used to perform updates.
I understand that Issue 735 and Issue 622 were opened for this, but they were closed with an unsatisfactory work around. The proposed workaround requires creating a custom class and explicitly designating certain fields to serialize even when null. This is inflexible and unusable for many situations.
Describe the ideal solution
I believe the ideal solution would implement something similar to the JsonNullable object container so that unset, explicit null, and value could all be represented within the values set on the API objects. Any nullable field should be wrapped in a container to accurately represent the states.
Alternatives and current workarounds
Current workarounds specified in previous tickets. Not really acceptable for situations that require field flexibility.
Additional context
Hi @prestongilchrist
Thank you for raising this and outlining the limitations with the current approach.
We understand PATCH operations should support (unset, explicitly null, and set) operations and current workaround is not the ideal one. We're actively evaluating better ways to handle null serialization in a future major version of the SDK ensuring good DX for Specifically PATCH operations.
In the meantime, the currently recommended workaround is described in #622.
Please feel free to share any additional examples or edge cases that can help in long-term solution.
Thanks again for the thoughtful feedback!