-
Notifications
You must be signed in to change notification settings - Fork 96
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
Enhance Attribute Name Validation to Handle Leading Numerics #705
Comments
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.
bflad
added a commit
that referenced
this issue
Mar 30, 2023
Reference: #705 The error diagnostic details will only contain this additional context if a numeric is detected.
bflad
added a commit
that referenced
this issue
Mar 30, 2023
Reference: #705 The error diagnostic details will only contain this additional context if a numeric is detected.
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 framework's attribute name validation is currently the regular expression
^[a-z0-9_]+$
. The Terraform configuration language forbids identifiers (how attribute names are handled) from beginning with numeric characters.Proposal
Adjust the attribute name validation regular expression to
^[a-z_][a-z0-9_]*$
. Technically the validation should also permit hyphens (-
), however the provider ecosystem has conventionally never used hyphens in attribute names, so the framework should remain opinionated here to prevent introducing practitioner confusion.References
The text was updated successfully, but these errors were encountered: