-
Notifications
You must be signed in to change notification settings - Fork 99
Description
Module version
v1.0.0
Use-cases
Provider developers should not need to drop down to the github.com/hashicorp/terraform-plugin-go/tftypes
type system for advanced use cases that require working with schema-based data directly. In particular, tfsdk.Config
, tfsdk.Plan
, and tfsdk.State
type Raw
fields are currently tftypes.Value
. Instead, providers should be able to work with the framework's type system for consistency, such as types.Object
. If the tftypes
data handling was still necessary by providers for whatever reason, they could still use the type implementations of ToTerraformValue()
and FromTerraformValue()
to roundtrip back and forth.
This effort would also help clean up a lot of framework internal logic that goes back and forth between the two type systems.
Proposal
This will require a large amount of design effort to complete successfully and this proposal is not currently exhaustive. It is being written in the context of closing out the generic #172.
Likely, some tftypes
functionality such as walking and transforming values may be desirable in the framework type system or at least available internally within the framework.
Then, one of the following approaches could be taken to expose the data using the framework's type system:
Existing Type Approach
Add a new exported types.Object
retrieval method to the existing tfsdk
types. Deprecate the Raw
field.
This introduces the least changes for providers and the framework, but does not fix the framework's technical debt imposed by the data storage being an exported tftypes.Value
. Without a setter method, this also means that providers must use (types.Object).ToTerraformValue()
to save the data back, which could be awkward.
New Type Approach
New schema-based data types could be introduced in the datasource
, provider
, and resource
packages based off the framework type system which deprecate the existing tfsdk
types. This enables fully executing the vision of each concept being self-contained within its own package in the framework. Various requests/responses would need the tfsdk
based fields to be deprecated in preference of new fields using the new types.
This approach would also allow a more tailored design that no longer exposes any implementation details as errantly mutable fields, but more design would be needed on that front.
Activity
attr.Value
s. #172bflad commentedon Dec 16, 2022
One additional note that I would like to cross-reference from #186 is that any potential new implementation of
GetAttribute()
andSetAttribute()
should consider only accepting a single attribute name path step or astring
that is wrapped as such. There are some difficulties and current inconsistencies with attempting to fetch data at deeper levels. Personally, I think it would be good to encourage the provider developer practice of working with the framework type system directly for nested data and creating new values, rather than trying to directly work with data based on deeper schema paths.resource/schema: Ensure invalid attribute default value errors are ra…
resource/schema: Ensure invalid attribute default value errors are ra…
resource/schema: Ensure invalid attribute default value errors are ra…
Squashed commit of the following:
all: Add dynamic type, attribute, and function support (#931)
all: Add dynamic type, attribute, and function support (#931)
Require provider-defined function parameter naming (#964)