-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Proposal: support multi-fields merge key #610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a8a2ae2
to
4766413
Compare
/assign @pwittrock @liggitt |
If a merge key only has one field, it will be the same as before, i.e. `patchMergeKey:"<key1>"`. | ||
|
||
There are no patch format changes. | ||
Additional fields are just extra fields in the patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional fields are just extra fields in the patch.
Patches for fields that have multiple fields in the merge key must include all of the fields part of the mergekey in the patch.
If a merge key only has one field, it will be the same as before, i.e. `patchMergeKey:"<key1>"`. | ||
|
||
There are no patch format changes. | ||
Additional fields are just extra fields in the patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the behavior if any of the fields are missing from the patch? Does the server reject the request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should reject that patch when it happens to a new API using multi-fields merge key.
Updated.
Alright, I think this has been discussed enough in the other PR, and there have been no objections. I am going to merge it. FYI: @liggitt @fabianofranz @adohe |
As @pwittrock suggested, break #476 to 2 proposals: