Unset Primitive Types on Optional Attributes with (State).Set() Generate Errors #201
Comments
bflad
added
bug
|
This is not an exhaustive list of proposals -- just capturing some initial thoughts. Proposal 1: Change type implementations to pointer types for ValueTheoretically, the implementations could introduce the following breaking changes so zero-value initialization can be detected: type Bool struct {
// Unknown will be true if the value is not yet known.
Unknown bool
// Value contains the value, as long as Unknown is false.
Value *bool
}
type Float64 struct {
// Unknown will be true if the value is not yet known.
Unknown bool
// Value contains the value, as long as Unknown is false.
Value *float64
}
type Int64 struct {
// Unknown will be true if the value is not yet known.
Unknown bool
// Value contains the value, as long as Unknown is false.
Value *int64
}
type String struct {
// Unknown will be true if the value is not yet known.
Unknown bool
// Value contains the value, as long as Unknown is false.
Value *string
}This would resolve the zero-value issue, as the This, however, does make working with the implementation much more difficult. For example, creating inline values is not directly possible in Go. e.g. something like this cannot be done // This example includes invalid Go code
types.String{Value: &"you cannot create a pointer of string literal"}This could be alleviated if the framework provided pointer conversion functions, e.g. func strPointer(str string) *string {
return &str
}Or types creation functions were introduced: // In types package
func NewString(str string) types.String {
return types.String{
Value: &str,
}
}Proposal 2: Allow and Recommend Pointers to Type ImplementationsSomething that doesn't work today is changing the target type implementation to use pointers to the type optionalTypesResourceTypeData struct {
ID string `tfsdk:"id"`
OptionalTypesBool *types.Bool `tfsdk:"optional_types_bool"`
OptionalTypesFloat64 *types.Float64 `tfsdk:"optional_types_float64"`
OptionalTypesInt64 *types.Int64 `tfsdk:"optional_types_int64"`
OptionalTypesString *types.String `tfsdk:"optional_types_string"`
}Currently this generates the following panic: This would alleviate the zero-value problem using the existing types since the values themselves are pointers and therefore remain unset unless set. The expectation in this case would be that Proposal 3: Return Framework Diagnostic for Zero-Value Versus Null DifferencesTheoretically, the framework can capture the case where the planned value is Proposal 4: Document Error and Fixes at https://www.terraform.io/docs/plugin/framework/writing-state.htmlWithout changing the code, this class of |
|
I think the latest proposal of switching the zero-value of the framework-defined types to null instead of (generally) a zero-value of the value is the best option here. That proposal is captured in #447 and I'm going to close this issue in preference of that issue since the other proposals captured here feel less than ideal. |
|
I am trying to set one of my schema Attribute to Int Pointer, Need some input how could i go about it ? |
|
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. |
Module version
Relevant provider source code
Terraform Configuration Files
Expected Behavior
Either framework generated errors with suggested fixes for the situation, documentation surrounding this problematic use case, or a successful apply with null values in the Terraform state for these optional attributes.
Actual Behavior
Terraform CLI returns error diagnostics:
Steps to Reproduce
terraform applyReferences
types.Numberis now fixed because its zero-value is anilpointer, which is then set to a null value)The text was updated successfully, but these errors were encountered: