-
Notifications
You must be signed in to change notification settings - Fork 94
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
Consider Whether Attribute (Or Subset) Should be Exposed in ModifyAttributePlanRequest #389
Comments
Reference: hashicorp#31 Reference: hashicorp#132 Reference: hashicorp#223 Reference: hashicorp#326 Reference: hashicorp#365 Reference: hashicorp#389 The main goals of this change are: - Prepare the Go module to support multiple packages that implement concept-specific schema declarations, in particular the `datasource`, `provider`, and `resource` packages - Continue supporting the existing `tfsdk` package schema implementation with minimal provider developer breaking changes, allowing a deprecation period when the concept-specific schemas are introduced - Migrate unexported or unintentially exported `tfsdk` schema functionality to internal packages These goals are accomplished by creating new `internal/fwschema` and `internal/fwxschema` packages, which contain interface types that the provider developer facing packages implement. Currently, the `tfsdk` package is the only implementation, until the design of those concept-specific schema declarations is fully determined. Those designs may include changes to schema implementation details, which cannot be accomplished in the existing `tfsdk` implementation without breaking it and provider developers migrating code to the new packages is a great time to make those types of changes. The internal interface method design here is purposefully similar to the existing `tfsdk` implementations as we cannot name the methods the same as existing fields and to reduce review burden. After the `tfsdk` implementations are removed, we can consider tidying up the interface methods to drop the `Get` and `Is` method name prefixes. There are some minor followup changes that will happen either between or during concept-specific schema implementation work, namely: - Swapping calls `tfsdk` package type `TerraformType()` methods for `AttributeType().TerraformType()` to reduce implementation work for new schema implementations - Updating unit testing that relies on `tfsdk.Schema` to set up sub-tests via `(*testing.T).Run()` to against multiple implementations These were not included here to reduce the review burden as they are separate details which can be handled later.
The new resource schema plan modifier for RequiresReplace now does not perform the |
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. |
Module version
Use-cases
Certain generic attribute plan modifiers will desire performing actions based on the
Attribute
definition itself. A current use case isRequiresReplace
andRequiresReplaceIf
, which currently have some checks for theComputed
field to preserve some terraform-plugin-sdk/v2 behavior that was present withForceNew
.Attempted Solutions
Using
req.State.Schema.AttributeAtPath(req.AttributePath)
to extract theAttribute
. This will require logic updates post #81, as the underlying implementation will remain*tftypes.AttributePath
until #365 is done.Proposal
First, we should decide if the top level
Attribute
definition should be exposed. This would be a brittle implementation detail for framework compatibility and provider developers may make unintended decisions based on exposing everything. The benefit however, is that provider developers do not need to jump through hoops to get the information as the framework would handle all the nitty gritty.Most (all?) plan modifiers shouldn't need that type of information though, except potentially
Computed
if they are logically treating that as special for legacy reasons. Another potential futureAttribute
field isDefault attr.Value
. If implemented, plan modifiers will most certainly warrant access to this value.Therefore an initial proposal here would be to only expose targeted
Attribute
fields, such asComputed
or optionallyDefault
if that becomes implemented. It would likely be best to let some of the referenced issues shake out first though, before making any implementation decisions.References
Attribute
will continue to haveComputed
field)Attribute
may introduceDefault
-like field)The text was updated successfully, but these errors were encountered: