Open chrismarget opened 1 year ago
Thanks for raising this, @chrismarget. 👍 My focus is elsewhere at the moment, but I wanted to drop some potential considerations here for you and future travelers.
A potential concern (outside booleans) is that using a single, static value associated with a Go built-in value type may become a scalability issue for this Go module. For example, strings might be desirable to be tested against regular expressions or numbers against ranges.
To mitigate that sort of concern, something to potentially consider in this context is whether something like a generic validation framework around "if" conditionals may be a less-specific solution to reduce the surface area to introduce type of functionality. Back with terraform-plugin-sdk, the customdiff
package implemented conditional helpers so it was possible to potentially decouple the conditional logic from needing to be re-introduced for every possible permutation (or at least made it consistent). Maybe something like stringvalidator.RequiredWhen(/* if logic */)
.
Potentially more outlandish in that space would be meta if-then support. Maybe something like stringvalidator.If(/* if logic*/, []validator.String)
. Then there is nothing new in this Go module required to make other validators conditional.
Another way to potentially frame this problem and potential solution is validating the opposite way -- similar to the existing AlsoRequires
validators but accepting a value based on the current attribute to trigger the behavior. e.g. stringvalidator.AlsoRequiresIfString(string, path.Expressions)
. Otherwise, this would already be covered with the "if-then" meta support mentioned above.
The joy of trying to design these. 😄
Hi @bflad,
I really like the stringvalidator.If()
idea.
Did ground rules for validator inclusion in this repo come together last week?
Terraform CLI and Framework Versions
any
Use Cases or Problem Statement
I have a need for schema attributes to be recognized as mandatory when certain values appear in other attributes.
For example, when
mode
is"complicated"
,complicated_mode_params
should be required.I'm thinking something like this:
Proposal
This situation could be generalized with validators for each attribute type which check for trigger values in other attributes of all types:
Same for
int64Validator
,mapValidator
,boolValidator
, etc...Comments elsewhere from @bflad indicate you're planning to set ground rules for validator inclusion this Friday, so I'm opening this issue with that in mind.
If there's interest, I could take a crack at it.
Additional Information
No response
Code of Conduct