-
Notifications
You must be signed in to change notification settings - Fork 63
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
Specifying {}
to remove nested fields should yield {}
, not nil
#259
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alexzielenski The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cc @apelisse |
@alexzielenski: 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-sigs/prow repository. I understand the commands that are listed here. |
Can we take the opportunity to summarize the various use-cases here that we've found so far? I'm getting a bit lost by the different possibilities and the differences they have. I suspect we should create a table for what happens when |
@@ -58,6 +60,9 @@ func (w *removingWalker) doList(t *schema.List) (errs ValidationErrors) { | |||
defer w.allocator.Free(l) | |||
// If list is null or empty just return | |||
if l == nil || l.Length() == 0 { | |||
if REMOVEKEEPEMPTYCOLLECTIONS { |
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.
Should we treat separately empty and nil here? Is that part of the problem?
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.
This change wasn't directly part of the problem I was trying to solve but I think something like this will be needed to have a consistent solution. The behavior of this right now always results in a nil
list even if you specify []
import ( | ||
"testing" | ||
|
||
"sigs.k8s.io/structured-merge-diff/v4/internal/fixture" |
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.
Aren't the other tests usually importing everything from fixture?
}, | ||
APIVersion: `v1`, | ||
Object: `{nestedMap: {}}`, | ||
}, |
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.
Yeah, so I guess now I'm confused about:
- What happens if we apply null instead.
- What happens if you have further level of nesting (i.e. you're apply
{}
when you had{'nested': {'numeric':1}}
(I'm guessing the same but would love to see) - How do you entirely remove the field? If null keeps null and {} keep it to empty, then how do you remove it altogether?
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.
Will add cases for 1 & 2
Re: 3. If you wanted to make {nestedMap: { myField: value }}
into {}
you would just apply {}
. If you applied {}
then nestedMap
field is included in the toRemove
set. If you had applied {nestedMap: {}}
then only nestedMap.myField
is in the toRemove
set, so nestedMap
would be retained yielding {nestedMap: {}}
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.
For the null case naively I would expect it to keep null if you specified null.
One last thing, I suspect lists and |
This bug also affects structs. There are valid CRDs that can be constructed with defined object fields where |
Hello. Is this fix planned to be merged soon? We currently have to bump our API cause we need to add the |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
Consider old object:
And patch, all with a single owner
I expect this to yield:
But today it yields:
Which results in an error on k8s since
nil
is not an acceptable value for thisrequiredField