[AIP-203] Clarify behavior when updating immutable fields. #516
Conversation
This came up in an internal discussion with @erictune. This does not represent a change in guidance, only a clarification to what we already tell people.
googlebot
added
the
cla: yes
aip/0203.md
Outdated
| When a service receives an immutable field in an update request (or similar), | ||
| even if included in the update mask, the service **should** ignore the field | ||
| and leave the existing value alone, but **should not** error. | ||
|
|
There was a problem hiding this comment.
Is this saying that it is never an error to try to change an immutable field using an update, but that it just doesn't do anything? If so, that seems confusing to users to debug what is going on.
Or is it saying something more subtle?
I would have expected it to say something like:
If an update request asks to change to an immutable field, then it should return an error. A change is defined as the value in the update differs from the value in the current state of the resources on the server, and that the field was included in the update mask.
If an update request mentions an immutable field but does not ask to change it, this should be ignored.
There was a problem hiding this comment.
If an update request asks to change to an immutable field, then it should return an error. A change is defined as the value in the update differs from the value in the current state of the resources on the server, and that the field was included in the update mask.
If an update request mentions an immutable field but does not ask to change it, this should be ignored.
I just realized I was thinking of output only, and not immutable, when I wrote that. For output only, we ignore all the time (because of things like update_time), but I agree that for immutable, we should error if a change is requested. Fixing.
| Potential use cases for immutable fields (this is not an exhaustive list) are: | ||
|
|
||
| - Names or IDs which are set on creation and then used as a primary key. | ||
|
|
||
| **Note:** Fields which are "conditionally immutable" **must not** be given the |
There was a problem hiding this comment.
Is "conditionally immutable" defined elsewhere? Does that mean things like "GCE instance size", which is immutable while the instance is powered on, but mutable if the instance is powered off?
As usual, I will update this before merging with the PR numbers for public comment. This PR is also contingent on #518 and #516 being merged. **Note:** I somehow goofed in the May newsletter and wrote "Friday, May 31" everywhere. The last Friday of May was May 29. I actually did the merge on May 29 and I am engaging in willful revisionist history.
This came up in an internal discussion with @erictune.
This does not represent a change in guidance, only a clarification
to what we already tell people.