Add plan modification support to attr.Type
#161
Labels
enhancement
New feature or request
types
Issues and pull requests about our types abstraction and implementations.
Milestone
Comments
paddycarver
added
the
types
bflad
added a commit
that referenced
this issue
Jun 22, 2022
Reference: #81 Reference: #161 Reference: #215 Reference: #365 This introduces a native abstraction over terraform-plugin-go's `tftypes.AttributePath`, allowing the framework to own the implementation details and extend the functionality further. Provider developers will be closer to removing a direct dependency on terraform-plugin-go. This is a major breaking change, however it is necessary before 1.0 to prevent compatibility issues in the future. This functionality is only intended to replace `tftypes.AttributePath` usage and not mess with the `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` type `tftypes.Value` data storage fields or their underlying data manipulation logic. This does leave the framework in an awkward half-state until those are further refactored (likely towards native `attr.Value`), but is done to try and reduce the review complexity of this initial migration. Additional followup changes will introduce the concept of path expressions, which will allow provider developers to match against multiple paths or reference parent paths in schema-based plan modifier and validation functionality. To prevent import cycles between `attr` and `diag` packages due changing the `attr.TypeWithValidate` type `Validate` method signature from `Validate(context.Context, tftypes.Value, *tftypes.AttributePath) diag.Diagnostics` to `Validate(context.Context, tftypes.Value, path.Path) diag.Diagnostics`, the `TypeWithValidation` interface is moved a new `xattr` package underneath `attr` with Go and website documentation to direct provider developers to the other package. This will also solve a prior issue with trying to implement `TypeWithModifyPlan` support. Naming and location of anything in this initial implementation can be adjusted as necessary. Provider developers can migrate to the new path handling by replacing: ```go tftypes.NewAttributePath().WithAttributeName("example") ``` With the equivalent: ```go path.RootPath("example") ``` Then using the `(Path).At*` methods to extend the path definition instead of `(*tftypes.AttributePath).With*` methods: | Current | New | | ------------------------ | --------------- | | `WithAttributeName()` | `AtName()` | | `WithElementKeyInt()` | `AtListIndex()` | | `WithElementKeyString()` | `AtMapKey()` | | `WithElementKeyValue()` | `AtSetValue()` |
bflad
added a commit
that referenced
this issue
Jun 22, 2022
#390) * path: Introduce package with initial tftypes.AttributePath abstraction Reference: #81 Reference: #161 Reference: #172 Reference: #365 This introduces a native abstraction over terraform-plugin-go's `tftypes.AttributePath`, allowing the framework to own the implementation details and extend the functionality further. Provider developers will be closer to removing a direct dependency on terraform-plugin-go. This is a major breaking change, however it is necessary before 1.0 to prevent compatibility issues in the future. This functionality is only intended to replace `tftypes.AttributePath` usage and not mess with the `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` type `tftypes.Value` data storage fields or their underlying data manipulation logic. This does leave the framework in an awkward half-state until those are further refactored (likely towards native `attr.Value`), but is done to try and reduce the review complexity of this initial migration. Additional followup changes will introduce the concept of path expressions, which will allow provider developers to match against multiple paths or reference parent paths in schema-based plan modifier and validation functionality. To prevent import cycles between `attr` and `diag` packages due changing the `attr.TypeWithValidate` type `Validate` method signature from `Validate(context.Context, tftypes.Value, *tftypes.AttributePath) diag.Diagnostics` to `Validate(context.Context, tftypes.Value, path.Path) diag.Diagnostics`, the `TypeWithValidation` interface is moved a new `xattr` package underneath `attr` with Go and website documentation to direct provider developers to the other package. This will also solve a prior issue with trying to implement `TypeWithModifyPlan` support. Naming and location of anything in this initial implementation can be adjusted as necessary. Provider developers can migrate to the new path handling by replacing: ```go tftypes.NewAttributePath().WithAttributeName("example") ``` With the equivalent: ```go path.Root("example") ``` Then using the `(Path).At*` methods to extend the path definition instead of `(*tftypes.AttributePath).With*` methods: | Current | New | | ------------------------ | --------------- | | `WithAttributeName()` | `AtName()` | | `WithElementKeyInt()` | `AtListIndex()` | | `WithElementKeyString()` | `AtMapKey()` | | `WithElementKeyValue()` | `AtSetValue()` |
|
(Old) example implementation for reference: #162 |
|
This is covered by #737 👍 |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Module version
Use-cases
Several types have semantically equivalent representations that are not byte-for-byte equivalent like Terraform requires. A JSON type comes to mind, in which
{ "key": "value" }and
{"key": "value"}should be considered equal, but Terraform treats as distinct values. By allowing plan modification strategies to be associated with
attr.Types, we can make sure this behavior is applied consistently everywhere the type is used.Attempted Solutions
We can work around this by adding an
AttributePlanModifierto eachschema.Attribute, but that requires consistency and extra work for provider developers that can be avoided.Proposal
Similar to
attr.TypeWithValidatewe create anattr.TypeWithModifyPlanthat allows defining plan modification for the type. This plan modification runs before attribute plan modification and before whole resource plan modification.The text was updated successfully, but these errors were encountered: