-
Notifications
You must be signed in to change notification settings - Fork 13
Adding Map validation for KeysAre and ValuesAre #38
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
Conversation
for k := range elems { | ||
request := tfsdk.ValidateAttributeRequest{ | ||
AttributePath: req.AttributePath.WithElementKeyString(k), | ||
AttributeConfig: types.String{Value: k}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit "hacky" to me. If a validator that is subsequently called by ranging over v.keyValidators
uses the AttributePath
to obtain the value for performing the validation this will break. Interested to hear opinions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is something to call in the Go documentation for the validator/function, but expected in this usage. The intention of the validator is to loop through the string
map keys to perform string
validations against those keys and the ValuesAre
validator is separate for this reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the docs to provide some clarification around this usage.
Following discussion with @detro we could consolidate the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 🚀
keysAreValidators: []tfsdk.AttributeValidator{ | ||
stringvalidator.LengthAtLeast(4), | ||
}, | ||
expectError: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: At some point it might be nice to refactor these validator tests to test the expected error messages, rather than just being conditional that some error was raised.
mapvalidator/type_validation_test.go
Outdated
gotMapElems, gotOk := validateMap(context.Background(), testCase.request, &tfsdk.ValidateAttributeResponse{}) | ||
|
||
if diff := cmp.Diff(gotMapElems, testCase.expectedMap); diff != "" { | ||
t.Errorf("unexpected float64 difference: %s", diff) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Copypasta typo 🍝
|
||
for k := range elems { | ||
request := tfsdk.ValidateAttributeRequest{ | ||
AttributePath: req.AttributePath.WithElementKeyString(k), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent choice here to highlight the whole key/value (at least I think it'll highlight the key too, but regardless, we do not have a way to signal upstream just a map key so this is a good compromise rather than just highlighting the whole map).
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. |
Closes: #13