Handling of default values
See original GitHub issueI got diffing objects working well so far, but there is one problem: Several properties in Kubernetes objects are scalars with default values. For example:
int ProbeV1.FailureThreshold
defaults to3
string ServicePortV1.Protocol
defaults to"TCP"
and many more. These properties are often not declared in YAML configuration. But when deserializing the YAML, the properties get the C# type default value, instead of the server default value. I.e.FailureThreshold
is always0
,Protocol
is alwaysnull
. When diffing against the server, this will then generate a patch that sets these values to the C# default value (0
/null
).
How should we handle this?
- When diffing, check if the new value is the C# default value, and exclude it from the patch. This would make it impossible to actually set a field to
0
ornull
. Does the API have fields anywhere that can be set to the C#/Go default value? E.g. forFailureThreshold
the minimum is1
, and in other places where0
is valid I saw them use nullable/pointer types, e.g.ConfigMapVolumeSource.DefaultMode
. But there are a lot of booleans that are not nullable, and this would make it impossible to switch a boolean back tofalse
after it was set totrue
on the server. - Apply the server defaults client side. This would break if they ever change the default. The defaults are only exposed through documentation, not in the schema.
- Make everything nullable. This would be a bad experience when querying from the server as these are always defined.
- Use Dictionaries or
dynamic
instead of strongly typed objects for deserialisation. I would like to avoid this because then we lose the formatting and autocompletion in PowerShell, and it becomes way harder to look up the merge strategies to use for properties…
Issue Analytics
- State:
- Created 5 years ago
- Comments:84 (55 by maintainers)
Top Results From Across the Web
Default values - are they good or evil?
Default values prevent stupid mistakes from the setup code. If the defaults are reasonable for most cases, fewer people mess with the working ......
Read more >DefaultValueHandling Enumeration
DefaultValueHandling Enumeration. Specifies default value handling options for the JsonSerializer. Namespace: Newtonsoft.Json
Read more >11.6 Data Type Default Values
Explicit Default Handling as of MySQL 8.0.13. The default value specified in a DEFAULT clause can be a literal constant or an expression....
Read more >c# - Default value for missing properties with JSON.net
I found the answer, just need to add the following attribute as well: [JsonProperty(DefaultValueHandling = DefaultValueHandling.Populate)].
Read more >General Rules for Default Values
The default value must be either a NULL, a constant value, a constant expression, an ERROR function, or an ABORT function. For input/output...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I implemented serialising into
PSObject
and diffingPSObject
and it works well. I am setting type names so output formatting is preserved. I think this is the best approach, so we can abandon the tracked models.Sorry, separation of concerns. I.e. not have one cmdlet that is solely responsible for parsing, diffing and querying the server. Because there may be use cases that we are not thinking of where one wants to intercept these steps.