Closed jabielecki closed 6 days ago
The combination of "put_create" and "data_source_name_query" seems a bit non-intuitive here, as "data_source_name_query" is meant to only affect data source(s). I would suggest to maybe only use the "put_create" flag if we anticipate this to be the expected implementation for this api. What do you think?
I would suggest to maybe only use the "put_create" flag
I did so, I agree. It seems most of the affected API calls do have some sort of GETALL query. In future we might find an incompatible one, it will be possible to add a dedicated boolean retroactively (put_create_name_query
).
Also, I've added comments to the peculiar behavior of DHCP, that seem to require three-valued boolean logic (true, false, null). The reason for this is because these three PUT bodies all behave differently:
First
"ipv4": {
"dhcp": { "enableDefaultRouteDHCP": true, "dhcpRouteMetric": 1 }
}
Second
"ipv4": {
"dhcp": { "enableDefaultRouteDHCP": false, "dhcpRouteMetric": 1 }
}
Third (this disables DHCP altogether, the two above enable DHCP).
"ipv4": {}
Description
Closes #57
Rebased initial yaml work from #12 by @kadadhic
Template feature added
With put_create true, always use code very similar to the data_source_name_query.
Reason: we assume API is a REST proper, and it means that PUT (used in Create instead of POST) requires an ID. Looking randomly at API spec it seems we can generally query by name from GETALL and obtain a good ID. Re-use the same code as applicable to data_source_name_query. (Almost the same - Create needs to deal with IsUnknown, not IsNull).
DHCPv4
The peculiar behavior of DHCP is that it seems to require three-valued boolean logic (true, false, null). The reason for this is because these three PUT bodies all behave differently:
First
Second
Third (this disables DHCP altogether, the two above enable DHCP).