Fixed TF<>API mapping for nested_query fine-grained resources#16591
Conversation
Also fixed ordering of the resource.go to expect api_resource_field to live alongside the other api-related fields Technically the mapping for etag will be wrong after this, but that's less wrong than the current state
| --- | ||
| name: 'ServicePerimeterEgressPolicy' | ||
| api_resource_type_kind: ServicePerimeter | ||
| api_resource_field: status.egressPolicies |
There was a problem hiding this comment.
What not source this information from
nested_query
Feels like we are duplicating this information in the config
There was a problem hiding this comment.
Fair point. I'll see if I can just pull this from nested_query instead.
There was a problem hiding this comment.
(For context, I think the reason I didn't do that in the first place was because not all the cases where this is needed have nested_query... but it may still be possible to pull from that when it is set.)
There was a problem hiding this comment.
yeah -- i think some resources do it in the decoder step -- which a bit frustrating. Ideally we would get rid of decoders where it can be implemented like a nested_query.
There was a problem hiding this comment.
I've made this change in de31560. It turns out there are two types of nested_query usage: fine-grained fields on resources, and resources that only have list endpoints instead of get. Pulling nested_query in automatically means that there needs to be a way to explicitly ignore nested_query. I've opted for api_resource_field: ".". (I also added a special-case to ignore "items" in nested_query, since that seems to always be an indication of list-type nested_query.) Let me know what you think!
There was a problem hiding this comment.
Could we bake the distinction into the nested_query object instead? Like object in list? I am find with your current solution but it is introducing some non-intuitive behavior.
There was a problem hiding this comment.
For now I'm going to keep this as-is... nested_query is very rarely used, so I'd prefer to avoid adding more flags to it if possible.
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Also fixed ordering of the resource.go to expect api_resource_field to live alongside the other api-related fields
Technically the mapping for etag will be wrong after this, but that's less wrong than the current state. Fixing that will require more thought than I want to (or can) put in right now.
Release Note Template for Downstream PRs (will be copied)
See Write release notes for guidance.