Closed SchoolGuy closed 2 months ago
So after a discussion with a colleague, I think the last option is the best one to make it easiest for consumers to work with the data. However, the issue here is that de/serialization would become potentially a lot more complicated. I will need to dig into the yaml, json and mapstructure de/serializers if we can make this work.
Another reason to transition to the last option is the potential future implementation of the backend in Golang. While Python is nice, it does have its drawbacks and we could synchronize the data types easier.
After starting to implement this locally I noticed that the get_item
XML-RPC API call has a parameter called flattened
. This parameter changes the type of certain dictionaries to string. This means that we need to account for this representation too since an inherited value can also be flattened.
Is your feature request related to a problem?
As a consumer of the Cobbler API
I want to be able to correctly handle properties that have multiple types
so that I can correctly handle the data exchange with the API.
Provide a detailed description of the proposed feature
The Golang Client should have native support for handling the special
<<inherit>>
value that some properties may have. Since Golang is strictly types we cannot handle this kind of multi-type properties without further code.I see at the moment two options for how to handle this kind of data:
interface{}
and use the methodIsValueInherit
to check what real type a certain field has.InheritedFields
array that must be checked before accessing the value. This would imply that adding a property name to this list would mean the value currently present would need to be set tonil
or a default value through reflection.Value
that is generic and containsinherited bool
and the concrete value.Alternatives you've considered
None
Additional information
Found while implementing the Golang CLI.