Conversation
aa0a2be to
859e205
Compare
Null() and Unknown() methods to value interfaceIsNull() and IsUnknown() methods to attr.Value interface
859e205 to
ebf9791
Compare
| # Jetbrains IDEs | ||
| .idea/ | ||
| *.iws |
There was a problem hiding this comment.
🙏 I just need to stop worrying about me fat-fingering it and open a PR with a bunch of Jetbrains files in it.
ebf9791 to
ba57490
Compare
bflad
left a comment
There was a problem hiding this comment.
Looks good to me 🚀
Let's ensure there is an associated changelog entry, e.g. .changelog/335.txt
```release-note:breaking-change
attr: The `Value` interface now requires the `IsNull()` and `IsUnknown()` methods
```
```release-note:enhancement
types: Added `IsNull()` and `IsUnknown()` methods to all types
```
internal/testing/types/bool.go
Outdated
| "context" | ||
| "fmt" | ||
|
|
||
| "github.com/hashicorp/terraform-plugin-go/tftypes" |
There was a problem hiding this comment.
Do you happen to have goimports enabled in your editor on save? It should revert this to the way it was.
There was a problem hiding this comment.
I have checked, and both Goland and goimports do the same thing: they seem to be putting "standard", then "3rd party", then "local" imports, separated by a space.
I thought that was the "Go way" to do imports, no?
There was a problem hiding this comment.
https://github.com/golang/go/wiki/CodeReviewComments#imports tends to be my jam. Not sure why certain things would default to splitting out the "local" imports group versus not.
| var ( | ||
| _ attr.Type = BoolType{} | ||
| _ attr.Type = BoolType{} | ||
| _ attr.Value = Bool{} |
There was a problem hiding this comment.
Thank you for adding these. 👍
This is of course reflected in all `types.*` implementing the interface.
2c25aa1 to
c995ce7
Compare
|
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. |
NOTE: This comes after a verbal conversation about this.
NOTE: This is a draft, to check a few things about the approach I'm taking. It's only applied to
Bool, so it's not the final PR.Background
As part of the work to port https://github.com/hashicorp/terraform-provider-tls/ to
terraform-plugin-framework, a need arises as soon as I attempted to implementAttributeValidatorandAttributePlanModifier.About plan modifiers
For plan modifiers, it's possible to implement a
defaultValueAttributePlanModifierthat when used looks like:And the implementation looks like:
If you look closely, we are having to convert back to TF types to check for null-ness. That feels sub-optimal (code smell?).
About validators
Similarly to the above, I wanted to implement
AttributeValidatorthat can be used to verify that an attribute was/wasn't set, in respect to other fields. This is a very useful declarative feature ofterraform-plugin-sdk/v2:This can be achieved in the framework by leveraging
tfsdk.ValidateAttributeReques.Config, that allows to interrogate the entire configuration while validating a single attribute.For example, this is how the equivalent of
RequiredWithlooks like:Unfortunately, like for plan modifiers, the implementations needs to convert back to TF types to interrogate null-ness. Writing
switchblocks and use type assertions could work, but it would then break for custom types, that is a feature of the new framework.Proposal
attr.Value, the interface implemented by everytypes.*, should contain extra methods:This would allow implementing key features like the above, way simpler/cleaner.
Future considerations
Follows a list of things we will not be addressing in this proposal PR, following the initial team consultation.
Un-export
UnknownandNullfields on concrete typesIt's a bit awkward to have on the concrete types both
.Unknownfields, as well as.IsUnknown()methods exported. We should probably look to ways to move the boolean field away from the public interface of those types. Maybe.unknownand.null?Constructor helpers
By virtue of the previous point, it would become necessary to provide some helper constructors to be able to create concrete types that set
.unknownand.nullfor us.For the
types.Booltype, they could maybe look like:tftypes.Value.IsFullyKnown()TF types offer an additional method called
IsFullyKnown(): this is the same asIsKnown()for primitive types, but it's useful for structured types likeObjects,Mapsetc. I could be beneficial for our structuredtypes.*?