-
Notifications
You must be signed in to change notification settings - Fork 18
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
Generate "expand" and "flatten" functions for associated external types #31
Comments
…ther than an array of objects (#31)
…r use with primitive attributes generic (#31)
…ute within single nested block that has an associated external type (#31)
…from model object template (#31)
* Remove recursion, and only process top-level primitive attributes within nested attributes and nested blocks
…le nested attributes and blocks (#31)
…ypes.Object passed into expand function is unknown (#31)
…ibutes to implementing AssocExtType (#31)
…es linked to list, map, set, single nested attributes and blocks (#32) * Bumping terraform-plugin-codegen-spec to c6dffeb (#31) * Updating IR JSON to use import object for associated_external_type rather than an array of objects (#31) * Initial implementation for generation of to-from (expand-flatten) functions (#31) * Add associated external type to single nested block in ir.json and update test data (#31) * Remove unused templates (#31) * Adding processing for bool with associated external type (#31) * Using a struct for attributes nested within a block (#31) * Adding type-specific fields for use with model object template (#31) * Adding types for use with attribute fields and making the template for use with primitive attributes generic (#31) * Using direct mapping for primitives in expand and flatten functions (#31) * Updated ir.json to include associated external type defined on attribute within single nested block that has an associated external type (#31) * Only suffix with newline if not already suffixed (#31) * Removing handling of nested primitives with associated external type from model object template (#31) * Remove processing of primitives with associated external type (#31) * Remove recursion, and only process top-level primitive attributes within nested attributes and nested blocks * Set-up generation of expand and flatten functions for single nested (#31) * Renaming template and fixing tests (#31) * Add handling for list nested attribute/block with associated external type (#31) * Add handling for map nested attribute with associated external type (#31) * Add handling for set nested attribute/block with associated external type (#31) * Add handling for list, map, set, single nested attributes and blocks for provider and resource (#31) * Wiring-up generation of expand and flatten for provider and resources (#31) * Loading imports for associated external type for list, map, set, single nested attributes and blocks (#31) * Returning error diagnostic when types.List, types.Map, types.Set or types.Object passed into expand function is unknown (#31) * Add handling in the expand functions for objects within a list, map or set that are unknown (#31) * Add handling in the flatten functions for api objects that could be nil (#31) * Consolidating logic (#31) * Refactored adding Imports() method to AssocExtType and switching attributes to implementing AssocExtType (#31)
Currently, terraform-plugin-codegen-openapi doesn't provide any field to map schema properties to associated_external_type. Is this something going to be supported in future as part of this issue ? |
Hey there @sachinsaxena-okta 👋🏻, The As for specifically the type of support possible in That's not a particularly great option, so we'll want to have a more concrete design before we start expanding support across other projects, like |
Thanks @austinvalle. We generated sdk for api client from openapi spec and thinking to map sdk types using associated_external_type. This will make very easy to call apis using sdk. I will wait for this work to be complete to see how it will be useful. |
Background
Given that Go uses static typing, when encountering “objects” with Go code it is very common that the API SDK (or other external code) implementation will use custom Go structure types for those objects. For example, a Terraform schema may need to describe an API with a list nested attribute (
types.List
oftypes.Object
), whereas the API SDK may implement an array/slice of a custom Go type. The provider developer is responsible for converting to and from the Terraform SDK types to the external types to properly generate API requests (Create
,Update
,Delete
) or handle API responses (Read
). This data handling logic can be cumbersome and it is almost exclusively repetitive depending on the API. Previously withterraform-plugin-sdk
, this type of provider logic was conventionally put into what developers called “expand” (Terraform to API) and “flatten” (API to Terraform) functions.Proposal
To ease developer burden, it is proposed that the associated_external_type, which can be optionally specified, be used in the generation of "expand" and "flatten" functions.
The following intermediate representation illustrates the usage of
associated_external_type
for a single nested block:In addition to the schema, models and model helper functions that are generated from the IR, the code generation would also create the following "expand" and "flatten" functions:
"Implicit" Mapping
The only fields that are currently defined within the schema for associated_external_type are
type
andimport
. Consequently, assumptions have to be made about how fields within an intermediate representation (IR) that have an associated_external_type defined should be handled when "expand" and "flatten" functions are generated.Primitives
Primitives are defined as the following types:
If the IR contains an associated_external_type for a primitive, the "expand" and "flatten" functions illustrated below will be generated.
Note that this assumes that the
associated_external_type.type
(e.g.,*apisdk.BoolType
) is something like the following:expand
flatten
The following assumptions have been made when implicitly mapping primitives:
Collections
Collections are defined as the following types:
If the IR contains an associated_external_type for a collection, the "expand" and "flatten" functions illustrated below will be generated.
Note that this assumes that the
associated_external_type.type
(e.g.,*apisdk.BoolSliceType
) is something like the following:expand
flatten
The following assumptions have been made when implicitly mapping collections:
ElementsAs(...)
. For example, if the schema defines the list attribute asschema.ListAttribute{ElementType: types.BoolType}
then associated_external_type.type would need to be a type that can be assigned[]*bool
.Object
Object is defined as the following type:
If the IR contains an associated_external_type for an object, the "expand" and "flatten" functions listed below will be generated.
The "expand" and "flatten" functions are generated on the basis of
schema.ObjectAttribute
andApiObject
having the following form:expand
flatten
The following assumptions have been made when implicitly mapping collections:
schema.ObjectAttribute
contains withinAttributeTypes
a"BoolAttribute": types.BoolType
the expectation is that theApiObject
will contain a field calledBoolAttribute
which holds*bool
).Nested Attributes and Blocks
Nested attributes and blocks are defined as the following types:
Single Nested Attribute without nested associated_external_type
If the IR contains an associated_external_type defined for a single nested attribute with no associated_external_type(s) defined on any of the attributes within the single nested attribute, then the "expand" and "flatten" functions listed below will be generated.
The "expand" and "flatten" functions are generated on the basis of
schema.SingleNestedAttribute
, andApiSingleNestedAttribute
having the following form:expand
flatten
Single Nested Attribute with nested associated_external_type(s)
If the IR contains an associated_external_type defined for a single nested attribute with associated_external_type(s) defined on the attributes within the single nested attribute, then the "expand" and "flatten" functions listed below will be generated.
The "expand" and "flatten" functions are generated on the basis of
schema.SingleNestedAttribute
, andApiSingleNestedAttribute
having the following form:expand
flatten
Further Considerations
Currently the IR Schema only permits the usage ofassociated_external_type
on data source, provider and resource single nested attributes. This will need to be extended to all attribute and block types.type
andimport
. Consequently some assumptions will need to be made about how the fields within the model struct are mapped to/from the fields in the "object" that is used for interaction with the API. An initial assumption would be that there is a direct one-to-one mapping unless/until a "mapping" field is defined forassociated_external_type
which allows for specifying how this translation from model to API object should happen.The text was updated successfully, but these errors were encountered: