The protobuf spec defines that default values are omitted from a message: if the receiver does not receive a value, it is assumed to be default.
I implemented sparse updates by only overwriting values in the object that are present in the message, but this is wrong.
In the protobuf spec, there is no way to distinguish an omitted member from a member that is set to its default value.
A possible workaround is to set the default value to something outside of the normal data range.
This complicates the design because:
We deviate from normal protobuf use
We have 'defaults' that are different from the actual default values of the values.
After discussion, we decided that we will remove the sparse update mechanism in its current form and an update to an object will write the entire object.
To update a single nested value the client can read the object, change a value and write the object back.
A future implementation to support sparse updates in a way that is compatible with the protobuf spec is to include a field mask in the message. The field mask, when present, indicates which values should be copied from the message.
The protobuf spec defines that default values are omitted from a message: if the receiver does not receive a value, it is assumed to be default.
I implemented sparse updates by only overwriting values in the object that are present in the message, but this is wrong. In the protobuf spec, there is no way to distinguish an omitted member from a member that is set to its default value.
A possible workaround is to set the default value to something outside of the normal data range. This complicates the design because:
To update a single nested value the client can read the object, change a value and write the object back.
A future implementation to support sparse updates in a way that is compatible with the protobuf spec is to include a field mask in the message. The field mask, when present, indicates which values should be copied from the message.