skip FixUpBlockAttrs when we can detect types from a new SDK #29624
Conversation
If structural types are being used, we can be assured that the legacy SDK SchemaConfigModeAttr is not being used, and the fixup is not needed. This prevents inadvertent mapping of blocks to structural attributes, and allows us to skip the fixup overhead when possible.
|
Definitely an edge case, but while we are here, would it be worth skipping on unsupported Block types as well? Terraform Plugin SDK version 2 only implements list and set blocks, unless hashicorp/terraform-plugin-sdk#62 / hashicorp/terraform-plugin-sdk#220 is ever implemented. |
|
I was thinking about also extending the heuristic to skip on attribute types that could not have been generated by the legacy SDK, like objects, and maps of objects. I didn't consider invalid schema block types too (they aren't part of this fixup at all), but maybe they're worth adding to increase the likelihood of a future positive signal even if blocks are in the SDK at all (yet)? |
|
Extended the heuristics to cover certain attribute types which were not generated by the legacy SDK. I did not add |
We can also rule out some attribute types as indicating something other than the legacy SDK. - Tuple types were not generated at all. - There were no single objects types, the convention was to use a block list or set of length 1. - Maps of objects were not possible to generate, since named blocks were not implemented. - Nested collections were not supported, but when they were generated they would have primitive types.
jbardin
force-pushed
the
jbardin/no-block-to-attr
branch
from
05279ac
to
8706a18
Compare
jbardin
changed the title
|
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. |
If structural types are being used, we can be assured that the legacy SDK SchemaConfigModeAttr is not being used, and the fixup is not needed. This prevents inadvertent mapping of blocks to structural attributes, and allows us to skip the fixup overhead when possible.
Here we have a passive alternative to #29572, requiring no input from the provider to prevent the collision of structural attributes and the block-to-attribute fixup. While we cannot use this technique to skip the fixup in all cases, the introduction of nested attribute types in the new SDK means that we will elide the fixup in the majority of cases with complex schemas.
The referenced PR contains some additional fixes, and a protocol 6.1 would still need to be cut to mark the deprecated fields, but those things can all be done in separate PRs.