The way we do updates today is using AIP's field masks. Each Update<Resource>Request message has a google.protobuf.FieldMask update_mask field to specify the paths of fields to merge.
Considering that merge semantics have proven to be hard to get right (Kubernetes went through many iterations to get it right, with strategic merge patch, JSON patch, JSON merge patch, SSA) and that AIP-161 is vague on how to deal with things like non-scalar values (maps and repeated fields), I'm worried we won't get it right either, even more so if we rush it.
This task proposes we start with whole-object updates. This would remove the update_mask field completely and leave the resource field as the only field in the Update<Resource>Request message. Clients will be able to fence the update on either version or UID in the same way they do it today to prevent clients from overwriting each other (i.e. blind updates).
Note that this decision doesn't preclude us from adding some form of patch updates in the future. For example, we could add the update_mask field and let the default (no mask) be whole-object replacement. On the other hand, getting the merge semantics wrong would put us in a bad place where we have to support that forever.
The way we do updates today is using AIP's field masks. Each
Update<Resource>Requestmessage has agoogle.protobuf.FieldMask update_maskfield to specify the paths of fields to merge.Considering that merge semantics have proven to be hard to get right (Kubernetes went through many iterations to get it right, with strategic merge patch, JSON patch, JSON merge patch, SSA) and that AIP-161 is vague on how to deal with things like non-scalar values (maps and repeated fields), I'm worried we won't get it right either, even more so if we rush it.
This task proposes we start with whole-object updates. This would remove the
update_maskfield completely and leave the resource field as the only field in theUpdate<Resource>Requestmessage. Clients will be able to fence the update on either version or UID in the same way they do it today to prevent clients from overwriting each other (i.e. blind updates).Note that this decision doesn't preclude us from adding some form of patch updates in the future. For example, we could add the
update_maskfield and let the default (no mask) be whole-object replacement. On the other hand, getting the merge semantics wrong would put us in a bad place where we have to support that forever.