-
Notifications
You must be signed in to change notification settings - Fork 13
Adding AtLeastSumOf
, AtMostSumOf
, EqualToSumOf
Validators
#29
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
a11d52a
to
a56e62f
Compare
requestConfigRaw: map[string]tftypes.Value{ | ||
"one": tftypes.NewValue(tftypes.Number, 15), | ||
"two": tftypes.NewValue(tftypes.Number, 15), | ||
}, |
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.
Drive-by note: It'd be great to ensure there are unit tests covering when the one/two attributes are null and/or unknown as well. Or all three are null/unknown.
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.
Have added some additional tests.
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.
These look great! Another good test case might be verifying that giving a path to an unexpected type (e.g. boolean attribute) always returns an error diagnostic. It appears the code should already be doing this, but it might be good to cover this for future code changes. Seems like it should be popping an additional attribute into the test schema, then referencing it in a new test case. 👍
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.
Have added a test case for attributePath(s) referencing unexpected types in at_least|at_most|equal_to_sum_of_test
.
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 looking already good. I'd just include more testing for unknowns/nulls scenarios (what @bflad said) and I'd offer these validators in a set:
- atLeastSumOf (i.e.
Attr >= Sum
) - atMostSumOf (i.e.
Attr <= Sum
) - sumOf (i.e.
Attr = Sum
)
5937dfd
to
49cdefb
Compare
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.
👩🍳 💋
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.
Getting pumped for this. Another thing we may want to consider, similar to #32, is whether we should wait for hashicorp/terraform-plugin-framework#81 to land and release upstream, as it will necessitate a breaking change for anything accepting attribute paths (or hopefully attribute path "expressions" in this use case).
int64validator/at_least_sum_of.go
Outdated
return | ||
} | ||
|
||
sumOfAttribs += attribToSum.Value |
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.
For code reader clarity, I'm not sure if its worth explicitly putting a conditional such as the below or a quick code comment why Value
is safe to always add (because its zero-value is 0)
if attribToSum.IsNull() || attribToSum.IsUnknown() {
continue
}
sumOfAttribs += attribToSum.Value
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.
Per #29 (comment), it may be better to implement something like:
if attribToSum.IsNull() {
continue
}
if attribToSum.IsUnknown() {
return
}
sumOfAttribs += attribToSum.Value
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.
Have added continue
statements for Null
and Unknown
to at_least|at_most|equal_to_sum
.
int64validator/at_least_sum_of.go
Outdated
// - Is exclusively at least the sum of the given attributes. | ||
// | ||
// Null (unconfigured) and unknown (known after apply) values are skipped. | ||
func AtLeastSumOf(attributesToSum []*tftypes.AttributePath) tfsdk.AttributeValidator { |
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.
Something we should probably decide on as a group is a common parameter style for "multiple attribute"/"combination"/"schema" validators -- I think I lean towards preferring a variadic style so consumers can omit the wrapping slice type syntax (e.g. []*tftypes.AttributePath{}
) and instead just list out the actual slice values, e.g.
// []*tftypes.AttributePath parameter
int64validator.AtLeastSumOf([]*tftypes.AttributePath{
tftypes.NewAttributePath().WithAttributeName("one"),
tftypes.NewAttributePath().WithAttributeName("two"),
})
// ...*tftypes.AttributePath parameter
int64validator.AtLeastSumOf(
tftypes.NewAttributePath().WithAttributeName("one"),
tftypes.NewAttributePath().WithAttributeName("two"),
)
If for some reason they already have a slice, then it can be expanded, e.g.
var mySpecialAttributes []*tftypes.AttributePath = []*tftypes.AttributePath{/*...*/}
int64validator.AtLeastSumOf(mySpecialAttributes...)
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.
Agreed. Have amended accordingly.
requestConfigRaw: map[string]tftypes.Value{ | ||
"one": tftypes.NewValue(tftypes.Number, 15), | ||
"two": tftypes.NewValue(tftypes.Number, 15), | ||
}, |
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.
These look great! Another good test case might be verifying that giving a path to an unexpected type (e.g. boolean attribute) always returns an error diagnostic. It appears the code should already be doing this, but it might be good to cover this for future code changes. Seems like it should be popping an additional attribute into the test schema, then referencing it in a new test case. 👍
int64validator/equal_to_sum_of.go
Outdated
// attribute value: | ||
// | ||
// - Is a number, which can be represented by a 64-bit integer. | ||
// - Is exclusively equal to the sum of the given attributes. |
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: Does the word "exclusively" apply here? 😄
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.
Fixed
FYI, moving this to v0.4.0 so we can release v0.3.0 with additional validators not dependent on hashicorp/terraform-plugin-framework#81, upgrade the framework dependency when its released, then focus immediately on these. |
AtLeastSumOf
, AtMostSumOf
, EqualToSumOf` Validators
AtLeastSumOf
, AtMostSumOf
, EqualToSumOf` ValidatorsAtLeastSumOf
, AtMostSumOf
, EqualToSumOf
Validators
1ac220c
to
de23465
Compare
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 you need to make use of path.Expressions
here, instead of pure Paths
. I left some details to why in the comment, but I'll also have an example of how I'm approaching this once I finish reworking the other PR.
de23465
to
f37d1cb
Compare
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.
The update to use the new .PathMatches
looks great, but I think we need to iron out what's the best behaviour for unknowns, when you are essentially trying to sum stuff up, to meet the validator's target.
Good thing we have a zoom in 15min.
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: #20
Couple of things:
null
this validator silently ignores that fact.unknown
, no errors are emitted as it's not possible to perform the validation.If this looks like it might be useful, let me know and I'll addHave addedatMostSumOf
and any other permutations that you think are appropriate into the same PR.atLeastSumOf
andequalToSumOf
.