-
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
Int64 Amount Validation (AtLeastSumOf, AtMostSumOf, EqualToSumOf) #20
Labels
enhancement
New feature or request
type/int64
types.Int64 validators
type/multi
Multiple attribute validators
Milestone
Comments
bendbennett
added
enhancement
New feature or request
type/int64
types.Int64 validators
labels
May 23, 2022
bendbennett
added a commit
that referenced
this issue
May 27, 2022
bendbennett
added a commit
that referenced
this issue
May 30, 2022
…ribute(s) are null or unknown for int64 atLeastSumOf (#20)
bendbennett
added a commit
that referenced
this issue
May 30, 2022
bendbennett
added a commit
that referenced
this issue
May 30, 2022
bendbennett
changed the title
Int64 Amount Validation (AtLeastSumOf)
Int64 Amount Validation (AtLeastSumOf, AtMostSumOf, EqualToSumOf)
May 30, 2022
bendbennett
added a commit
that referenced
this issue
May 30, 2022
bendbennett
added a commit
that referenced
this issue
Jun 9, 2022
bflad
added a commit
to hashicorp/terraform-plugin-framework
that referenced
this issue
Jun 28, 2022
Reference: #81 Reference: hashicorp/terraform-plugin-framework-validators#14 Reference: hashicorp/terraform-plugin-framework-validators#15 Reference: hashicorp/terraform-plugin-framework-validators#16 Reference: hashicorp/terraform-plugin-framework-validators#17 Reference: hashicorp/terraform-plugin-framework-validators#20 This introduces the concept of an attribute path expression, an abstraction on top of an attribute path, which enables provider developers to declare logic which might match zero, one, or more paths. Paths are directly convertable into path expressions as exact expression steps. The builder-like syntax for exact expression steps matches the syntax for path steps, such as `AtName()` in both cases always represents an exact transversal into the attribute name of an object. Additional expression steps enable matching any list, map, or set element, such as `AtAnyListIndex()`. It also supports relative attribute path expressions, by supporting a parent expression step `AtParent()` or starting an expression with `MatchParent()` which can be combined with a prior path expression. The framework will automatically expose path expressions to attribute plan modifiers and validators, so they can more intuitively support relative paths as inputs to their logic. For example, the `terraform-plugin-framework-validators` Go module will implement support for `terraform-plugin-sdk` multiple attribute schema behaviors such as `ConflictsWith`. It is expected that the downstream implementation can allow provider developers to declare the validator with expressions such as: ```go tfsdk.Attribute{ // ... other fields ... Validators: []AttributeValidators{ schemavalidator.ConflictsWith( // Example absolute path from root path.MatchRoot("root_attribute"), // Example relative path from current attribute // e.g. another attribute at the same list index of ListNestedAttributes path.MatchParent().AtName("another_same_level_attribute"), ), }, } ``` Then the logic within the validator can take the `ValidateAttributeRequest.AttributePathExpression` and use the `(path.Expression).Append()` method to combine the current attribute expression with any incoming expressions. While this introduction will expose the expression types and make them available to attribute plan modifiers and validators, there is not yet a simple methodology for getting valid paths within data stored in `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` that match the expression. This will be added after this initial expression API is reviewed and approved.
bflad
added a commit
to hashicorp/terraform-plugin-framework
that referenced
this issue
Jun 29, 2022
Reference: #81 Reference: hashicorp/terraform-plugin-framework-validators#14 Reference: hashicorp/terraform-plugin-framework-validators#15 Reference: hashicorp/terraform-plugin-framework-validators#16 Reference: hashicorp/terraform-plugin-framework-validators#17 Reference: hashicorp/terraform-plugin-framework-validators#20 This introduces the concept of root and relative attribute path expressions, abstractions on top of an attribute path, which enables provider developers to declare logic which might match zero, one, or more paths. Paths are directly convertible into path expressions as exact expression steps. The builder-like syntax for exact expression steps matches the syntax for regular path steps, such as `AtName()` in both cases always represents an exact transversal into the attribute name of an object. Additional expression steps enable matching any list, map, or set element, such as `AtAnyListIndex()`. It also supports relative attribute path expressions, by supporting a parent expression step `AtParent()` and starting an expression with `MatchRelative()` so it can be combined with a prior path expression. The framework will automatically expose path expressions to attribute plan modifiers and validators, so they can more intuitively support relative paths as inputs to their logic. For example, the `terraform-plugin-framework-validators` Go module will implement support for `terraform-plugin-sdk` multiple attribute schema behaviors such as `ConflictsWith`. It is expected that the downstream implementation can allow provider developers to declare the validator with expressions such as: ```go tfsdk.Attribute{ // ... other fields ... Validators: []AttributeValidators{ schemavalidator.ConflictsWith( // Example absolute path from root path.MatchRoot("root_attribute"), // Example relative path from current attribute // e.g. another attribute at the same list index of ListNestedAttributes path.MatchRelative().AtParent().AtName("another_same_level_attribute"), ), }, } ``` Then the logic within the validator can take the `ValidateAttributeRequest.AttributePathExpression` and use the `(path.Expression).Merge()` method to combine the current attribute expression with any incoming expressions. To find matching attribute paths based on a path expression within `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State`, a `PathMatches(path.Expression)` method has been added to each type. The resulting paths can then be used to fetch data via existing functionality, such as the `GetAttribute()` method of each type.
bendbennett
added a commit
that referenced
this issue
Jul 6, 2022
bendbennett
added a commit
that referenced
this issue
Jul 6, 2022
bendbennett
added a commit
that referenced
this issue
Jul 6, 2022
…f and EqualToSumOf validators (#20)
bendbennett
added a commit
that referenced
this issue
Jul 13, 2022
bendbennett
added a commit
that referenced
this issue
Jul 13, 2022
bendbennett
added a commit
that referenced
this issue
Jul 13, 2022
…f and EqualToSumOf validators (#20)
bendbennett
added a commit
that referenced
this issue
Jul 13, 2022
detro
pushed a commit
that referenced
this issue
Jul 20, 2022
* Adding atLeastSumOf, atMostSumOf and equalToSumOf int64 validators (#20) * Switching to using path expressions * Do not validate if any attributes are unknown (#20) * Updating dependencies, including terraform-plugin-framework@0.10.0 * PR review: making use of the new `path.Expression` `.MergeExpressions` method * Preparing CHANGELOG entry * Rely on 'tfsdk.ValueAs' to do type validation Co-authored-by: Ivan De Marino <ivan.demarino@hashicorp.com> Co-authored-by: Brian Flad <bflad417@gmail.com>
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
enhancement
New feature or request
type/int64
types.Int64 validators
type/multi
Multiple attribute validators
Terraform CLI and Framework Versions
Any Terraform CLI version; terraform-plugin-framework v0.8.0
Use Cases or Problem Statement
Provider developers should be able to generically validate
types.Int64
values for their amount/size. For example:Proposal
Inside a
int64validator
package, create one new unexported types that satisfy thetfsdk.AttributeValidator
interface:Then, create exported functions that return these:
This would allow provider developers to declare attributes such as:
Additional Information
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: