-
Notifications
You must be signed in to change notification settings - Fork 12
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
Introducing schemavalidator
package
#32
Conversation
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.
Nice!
Drive-by comment: |
I'm not personally sure why they're being moved under |
@ewbankkit @bflad about the move under About the new validators, I was reading the doc that @bflad put down for native |
I may or may not have visceral reactions due to The I've mentioned out of band from GitHub that it might be good to wait to merge and release these until hashicorp/terraform-plugin-framework#81 is sorted upstream, just so we don't immediately have to introduce that breaking change here. 👍 I also think you and @bendbennett have been working pretty closely on these, so please reach out if any of my feedback from #29 doesn't make sense. |
587307a
to
8153099
Compare
combovalidator
packageschemavalidator
package
9c8dd47
to
e5e117e
Compare
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. |
a89d000
to
60886e2
Compare
…ath.Expressions` manipulation
60886e2
to
e3b6a99
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.
Overall it's shaping up really good -- I think we should discuss the semantics of unknown values some more though before committing to these as written.
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Brian Flad <bflad417@gmail.com>
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.
Just some additional drive-by notes about the latest code. Happy to have the unknown values discussion anytime.
I also wonder if we should still consider creating DataSourceConfigValidator
/ProviderConfigValidator
/ResourceConfigValidator
implementations of these to suit provider developer styles as noted in the original issues because sometimes basing multiple attribute validation on a particular attribute can be confusing or duplicative (both in code and returned diagnostics), e.g.
"attr1": tfsdk.Attribute{
Validators: []tfsdk.AttributeValidator{
schemavalidator.ConflictsWith(path.MatchRoot("attr2")),
},
}
"attr2": tfsdk.Attribute{
Validators: []tfsdk.AttributeValidator{
schemavalidator.ConflictsWith(path.MatchRoot("attr1")),
},
}
Would return two similar error diagnostics (one for each attribute validator) versus something like:
func (r exampleResource) ConfigValidators(ctx context.Context) []tfsdk.ResourceConfigValidator {
return []tfsdk.ResourceConfigValidator{
configvalidator.ConflictingAttributes(
path.MatchRoot("attr1"),
path.MatchRoot("attr2"),
),
}
}
Those *ConfigValidator
implementations don't need to be part of this PR, but I worry about closing the original issues without at least creating followup ones to support the other declaration style. Refer also to hashicorp/terraform-plugin-sdk#286. I also need to ensure there is an issue in terraform-plugin-framework that allows a single configuration validator to work across all three of DataSource/Provider/Resource; I'm pretty sure the Validate() method of each is conflicting at the moment, which was an oversight in the original implementation.
schemavalidator/required_with.go
Outdated
return fmt.Sprintf("Ensure that if an attribute is set, also these are set: %q", av.pathExpressions) | ||
} | ||
|
||
func (av requiredWithAttributeValidator) Validate(ctx context.Context, req tfsdk.ValidateAttributeRequest, res *tfsdk.ValidateAttributeResponse) { |
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 believe if the current attribute with the validator is null, the rest of the logic can be skipped.
func (av requiredWithAttributeValidator) Validate(ctx context.Context, req tfsdk.ValidateAttributeRequest, res *tfsdk.ValidateAttributeResponse) { | |
func (av requiredWithAttributeValidator) Validate(ctx context.Context, req tfsdk.ValidateAttributeRequest, res *tfsdk.ValidateAttributeResponse) { | |
if req.AttributeConfig.IsNull() { | |
return | |
} | |
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.
About this one I'm a bit perplexed.
The issue is, if this is "requiredWith", we need to establish if it's NULL whilst the other it's required to be with are NOT NULL.
It should instead fail when the attribute is NULL, but the one its required to be required with aren't.
schemavalidator/required_with.go
Outdated
return | ||
} | ||
|
||
if !req.AttributeConfig.IsNull() && mpVal.IsNull() { |
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.
Paired with the above check if the current attribute with the validator is null:
if !req.AttributeConfig.IsNull() && mpVal.IsNull() { | |
if mpVal.IsNull() { |
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.
See above, why I'm perplexed with this one.
In regards to having also the One thing that working on those validators showed me, is that while they fulfil the need and match the SDK featureset, the resource/data-source/provider level ones, for schema validation, are WAY better suited. So I'm going to do create an additional issue to track the work to add those kinds of validators, so we don't lose track of this need, but we can still close the existing issues I was targeting here. |
…ath.Expressions`
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.
Approving the changes outside my own
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 #14
Closes #15
Closes #16
Closes #17
NOTE: This PR depends on changes in terraform-plugin-framework that will land in v0.10.0. To allow tests to pass, I have temporarily set the
go.mod
to pullmain
branch: to do thev0.4.0
release, we will have to wait on FW to ship, then we will updatego.mod
, and then cut it.