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
internal/fwserver: Use existing data instead of path-based lookups during plan modification #468
Conversation
…ring plan modification Reference: #293 This change is a major rewrite of the plan modification logic to move away from globally mutating the schema response to instead localize handling of each attribute/block. The logic still transverses downward in the schema while updated plan modifier values are passed up the call stack to eventually overwrite the top level attribute/block data. The main benefit of this logic is that it cannot lose track of which element to update within a set and may have some nominal performance improvements. The majority of the logic changes are convincing the plan modification process that nested attributes and blocks have specific types for their data, which allows it to safely traverse deeper based on the schema definition. There is just a lot of repeated diagnostics handling.
Taking a fresh look at this PR this morning, I think this is something we do want to do for now. I'm really sorry for the awful Git differences with the testing code, but essentially the changes were to replace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Benjamin Bennett <ben.bennett@hashicorp.com>
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #293
This change is a major rewrite of the plan modification logic to move away from globally mutating the schema response to instead localize handling of each attribute/block. The logic still transverses downward in the schema while updated plan modifier values are passed up the call stack to eventually overwrite the top level attribute/block data. The main benefit of this logic is that it cannot lose track of which element to update within a set and may have some nominal performance improvements.
The majority of the logic changes are convincing the plan modification process that nested attributes and blocks have specific types for their data, which allows it to safely traverse deeper based on the schema definition. There is just a lot of repeated diagnostics handling.
The new
TestAttributeModifyPlan/attribute-set-nested-usestateforunknown
andTestBlockModifyPlan/block-set-nested-usestateforunknown
unit test cases specifically test a similar issue to the linked one where sets previously could not properly useresource.UseStateForKnown()
for set nested attributes or set blocks.