-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Remove null -> [] slice hack #45294
Remove null -> [] slice hack #45294
Conversation
/unassign @dims |
@smarterclayton the type aliasing needed to get custom json encoding is throwing off the protobuf encoder: - Subsets []EndpointSubset `json:"subsets" protobuf:"bytes,2,rep,name=subsets"`
+ Subsets EndpointSubsetList `json:"subsets" protobuf:"bytes,2,rep,name=subsets"`
}
+// EndpointSubsetList represents a list of EndpointSubset objects.
+type EndpointSubsetList []EndpointSubset is resulting in generated protobuf code like this: - m.Subsets = append(m.Subsets, EndpointSubset{})
+ m.Subsets = append(m.Subsets, EndpointSubsetList{}) any ideas? |
I wonder if defining a method on the type (or using a pointer??) confuses
the generated code. There's a rewrite step in go-to-protobuf that uses AST
traversal - it's possible that the change in traversal means the matchers
don't match anymore
…On Wed, May 3, 2017 at 3:35 PM, Jordan Liggitt ***@***.***> wrote:
@smarterclayton <https://github.com/smarterclayton> the type aliasing
needed to get custom json encoding is throwing off the protobuf encoder:
- Subsets []EndpointSubset `json:"subsets" protobuf:"bytes,2,rep,name=subsets"`+ Subsets EndpointSubsetList `json:"subsets" protobuf:"bytes,2,rep,name=subsets"`
}
+// EndpointSubsetList represents a list of EndpointSubset objects.+type EndpointSubsetList []EndpointSubset
is resulting in generated protobuf code like this:
- m.Subsets = append(m.Subsets, EndpointSubset{})
+ m.Subsets = append(m.Subsets, EndpointSubsetList{})
any ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#45294 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p42euwdMkHMGaqKLb6FcZzbrYdzMks5r2NcIgaJpZM4NPuTK>
.
|
@smarterclayton - got this working, PTAL |
@wojtek-t PTAL at toUnstructured changes in the "Fix unstructured marshaler to handle all JSON types" commit |
Those changes (last commit) LGTM. |
c15c2aa
to
4bd7429
Compare
LGTM. I have no objections and follow Jordan's reasoning on this. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, smarterclayton, thockin Associated issue: 44593 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/retest |
1 similar comment
/retest |
/retest Review the full test history for this PR. |
2 similar comments
/retest Review the full test history for this PR. |
/retest Review the full test history for this PR. |
@liggitt: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/retest Review the full test history for this PR. |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Automatic merge from submit-queue (batch tested with PRs 45345, 49470, 49407, 49448, 49486) Fix unstructured marshaler to handle all JSON types Split from kubernetes/kubernetes#45294 /assign @wojtek-t Kubernetes-commit: 17b9c21a6aca1da03ce0ca1eb6e79eeebf133e3a
Closes #44593
When 1.6 added protobuf storage, the storage layer lost the ability to persist slice fields with empty but non-null values.
As a workaround, we tried to convert empty slice fields to
[]
, rather thannull
. Compressingnull
->[]
was just as much of an API breakage as[]
->null
, but was hoped to cause fewer problems in clients that don't do null checks.Because of conversion optimizations around converting lists of objects, the
null
->[]
hack was discovered to only apply to individual get requests, not to a list of objects. 1.6 and 1.7 was released with this behavior, and the world didn't explode. 1.7 documented the breaking API change thatnull
and[]
should be considered equivalent, unless otherwise noted on a particular field.This PR:
get
consistent with the results oflist
(which helps naive clients that do deepequal comparisons of objects obtained via list/watch and get), and allows empty slice fields to be returned asnull