Support Block Plan Modification #222
Assignees
Labels
enhancement
New feature or request
schema
Issues and pull requests about the abstraction for specifying schemas.
Milestone
Comments
bflad
added
enhancement
This was referenced Nov 2, 2021
bflad
added a commit
that referenced
this issue
Nov 3, 2021
Reference: #85 The primary purpose for supporting blocks is to allow previously existing schemas defined by the older Terraform Plugin SDK to not require practitioner breaking changes upon migrating to the framework (except the protocol version and therefore the minimum Terraform CLI version unless a tfprotov5 server implementation is added to this framework as well). This also allows this framework to be muxed with the older framework since the provider schema must match. It is expected that over time any schema definitions including `Blocks` will migrate to `Attributes`. Provider developers should always opt for `Attributes` in new schema definitions. One notable exclusion to this initial block support is plan modification, both with attributes under blocks and blocks themselves. Support for this functionality can be tracked in #222.
bflad
added a commit
that referenced
this issue
Nov 11, 2021
Reference: #222 Adds `PlanModifiers` within `Block`s and ensures any children attribute and block plan modifiers of a `Block` are executed. The dual response parameter pattern is twofold necessary, or rather a simpler implementation, due to the current details: * `AttributePlanModifier`s return a `RequiresReplace` boolean, which the caller is responsible for setting the proper attribute path for the overall schema response. * `AttributePlanModifier`s return `AttributePlan` as an `attr.Value`, which cannot be directly set into a parent value without reimplementing all the `SetAttribute()` logic for handling nil/null/unknown values, so it is left to the caller to properly call `(Plan).SetAttribute()` in the schema response.
bflad
added a commit
that referenced
this issue
Nov 19, 2021
Reference: #222 Adds `PlanModifiers` within `Block`s and ensures any children attribute and block plan modifiers of a `Block` are executed.
|
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
The initial block support of #85 may not contain plan modification support for the block itself or underlying attributes to reduce the complexity of first round code changes. This support should be added for parity with attributes and to prevent provider developer confusion.
Proposal
Add
PlanModifiersfield to theBlocktype and wire with schema plan modification. Ensure eachAttributeunderBlock.Attributesproperly handles theirPlanModifiersfield.The text was updated successfully, but these errors were encountered: