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

Implement function parameter interfaces for logical validators (All, Any, etc.) #239

Open
1 task done
austinvalle opened this issue Oct 14, 2024 · 0 comments
Open
1 task done
Labels
enhancement New feature or request

Comments

@austinvalle
Copy link
Member

Terraform CLI and Framework Versions

N/A

Use Cases or Problem Statement

Following #238, the remaining validators that don't support parameter validation (used in provider-defined functions) that are able to are:

  • Any + AnyWithAllWarnings for all validator packages
  • All for all validator packages
  • mapvalidators.KeysAre
  • Value{TYPE}sAre for all collection validator packages, like listvalidator.ValueStringsAre

Proposal

These "logical" validators all accept in the attribute-based validator interface, like validator.String, which differ from the parameter-based validator interface, like function.StringParameterValidator. The differences are small however (notably error handling and data available), and are not relevant for the mentioned validators.

These validators all accept the attribute-based validator as input and we'd prefer to not introduce breaking changes by modifying/adding new inputs.

Two possible options I see (there could be others!):

  1. In these validators, add type assertion logic to split/distinguish which validations should run on parameters vs. attributes and handle everything internally.
  2. Introduce new Any/All/etc. variants that only work with parameter-based validation and accept that interface as input

Overall I think 1 is more preferable, however that does mean that anyone wanting to use the All/Any/etc. validators with function parameters would need to implement the attribute-based interface on any sub validators. This isn't necessarily a problem for the common validators in this Go module, but could be annoying for custom validators.

Additional Information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
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

1 participant