Skip to content
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

Handle Nested Attributes and Nested Blocks Using List, Set and Map When Validating Attribute Field Names #574

Open
bendbennett opened this issue Dec 12, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@bendbennett
Copy link
Contributor

Module version

v0.17

Use-cases

for k, v := range attributes {
	d := validateAttributeFieldName(path.AtName(k), k, v)
for k, v := range blocks {
	d := validateBlockFieldName(path.AtName(k), k, v)

Since the nested attributes might be done using list, map, or set mode, we'll also need to account for adding those intermediate steps (AtListIndex, AtMapKey, AtSetValue) to the path.

Attempted Solutions

N/A

Proposal

Fix up the path information and consider including it in the diagnostic details in case it is not in Terraform's output. Maybe we can use something like the zero-value (e.g. AtListIndex(0), AtMapKey(""), AtSetValue(/* ? */)) for describing those intermediate path steps for static validation.

References

@bendbennett bendbennett added the enhancement New feature or request label Dec 12, 2022
bflad added a commit that referenced this issue Mar 29, 2023
…event AttributeTypes/ElementType field panics

Reference: #574
Reference: #699
Reference: #704
Reference: #705

The goal of this change is to enable easier schema validation within the framework logic. This is achieved by implementing new internal interfaces that implement shared logic across all schema types, then introduce methods on attribute types which currently implement type-specific validation logic.

The new `ValidateImplementation()` methods on attribute types, while technically exported, cannot be implemented externally due to their usage of internal types. This follows the existing implementation of the framework where attribute types already cannot be extended due to the `Equal(fwschema.Attribute)` method requirement. Therefore these new `ValidateImplementation()` methods do not need to worry about compatibility promises and can be modified or removed in the future.

This change also includes some breadcrumbs for other schema validation requests.
bflad added a commit that referenced this issue Mar 30, 2023
…event AttributeTypes/ElementType field panics (#706)

Reference: #574
Reference: #699
Reference: #704
Reference: #705

The goal of this change is to enable easier schema validation within the framework logic. This is achieved by implementing new internal interfaces that implement shared logic across all schema types, then introduce methods on attribute types which currently implement type-specific validation logic.

The new `ValidateImplementation()` methods on attribute types, while technically exported, cannot be implemented externally due to their usage of internal types. This follows the existing implementation of the framework where attribute types already cannot be extended due to the `Equal(fwschema.Attribute)` method requirement. Therefore these new `ValidateImplementation()` methods do not need to worry about compatibility promises and can be modified or removed in the future.

This change also includes some breadcrumbs for other schema validation requests.
@austinvalle austinvalle added the tf-devex-triage Terraform DevEx project tracking label Jul 31, 2023
@bookshelfdave bookshelfdave removed the tf-devex-triage Terraform DevEx project tracking label Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants