Consider Refactoring tfsdk Config/Plan/State Logic into internal Package(s) #366
Comments
bflad
added
tech-debt
bflad
added a commit
that referenced
this issue
Jul 29, 2022
…packages Reference: #132 Reference: #365 Reference: #366 Since the framework's initial release, the `tfsdk` Go package has been a monolithic collection of various provider concepts, including but not limited to handling of data sources, providers, resources, schemas, schema data (such as `Config`, `Plan`, and `State`), and various other helpers. For framework maintainers, this monolithic package has made implementations difficult for certain enhancements, such as import cycles. For provider developers, this monolithic package has been difficult to navigate in the Go documentation. This change represents the first major provider coding paradigm shift to colocate related concepts into their own Go packages, starting with new top-level `datasource`, `provider`, and `resource` packages. Overall the changes, other than the migration effort, should feel welcome as it will be much easier to discover related functionality and there is some reduced wordiness. This particular change and method (no deprecation period) was not desired, but it was unavoidable due to the interconnectedness of the `tfsdk` package and due to the amount of effort it would require to attempt to support both the old and new types. This change is necessary to complete before there are additional code compatibility promises added to this Go module, such as a version 1.0.0 release or release candidate. This type of change is not taken lightly, as it is quite disruptive for existing provider codebases. It is unclear at the time of writing whether splitting out the other concepts from the `tfsdk` package, such as schemas, will present the same issues. Regardless, any other major changes will be spread across releases. Provider developers should be able to update their code using find and replace operations using the tables below. To reduce framework maintainer review burden, all code migrations were lift and shift operations while most code and documentation updates were find and replace operations. ### Providers | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ConfigureProviderRequest` | `provider.ConfigureRequest` | | `tfsdk.ConfigureProviderResponse` | `provider.ConfigureResponse` | | `tfsdk.Provider` | `provider.Provider` | | `tfsdk.ProviderConfigValidator` | `provider.ConfigValidator` | | `tfsdk.ProviderWithConfigValidators` | `provider.ProviderWithConfigValidators` | | `tfsdk.ProviderWithProviderMeta` | `provider.ProviderWithMetaSchema` (note naming realignment) | | `tfsdk.ProviderWithValidateConfig` | `provider.ProviderWithValidateConfig` | | `tfsdk.ValidateProviderConfigRequest` | `provider.ValidateConfigRequest` | | `tfsdk.ValidateProviderConfigResponse` | `provider.ValidateConfigResponse` | ### Data Sources The `DataSourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `DataSource`. Other data source concept types are migrated to a new `datasource` package. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.DataSourceType` | `provider.DataSourceType` | | Prior tfsdk Package Type | New datasource Package Type | | --- | --- | | `tfsdk.DataSource` | `datasource.DataSource` | | `tfsdk.DataSourceConfigValidator` | `datasource.ConfigValidator` | | `tfsdk.DataSourceWithConfigValidators` | `datasource.DataSourceWithConfigValidators` | | `tfsdk.DataSourceWithValidateConfig` | `datasource.DataSourceWithValidateConfig` | | `tfsdk.ReadDataSourceRequest` | `datasource.ReadRequest` | | `tfsdk.ReadDataSourceResponse` | `datasource.ReadResponse` | | `tfsdk.ValidateDataSourceConfigRequest` | `datasource.ValidateConfigRequest` | | `tfsdk.ValidateDataSourceConfigResponse` | `datasource.ValidateConfigResponse` | ### Resources The `ResourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `Resource`. Other resource concept types are migrated to a new `resource` package. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ResourceType` | `provider.ResourceType` | | Prior tfsdk Package Type | New resource Package Type | | --- | --- | | `tfsdk.CreateResourceRequest` | `resource.CreateRequest` | | `tfsdk.CreateResourceResponse` | `resource.CreateResponse` | | `tfsdk.DeleteResourceRequest` | `resource.DeleteRequest` | | `tfsdk.DeleteResourceResponse` | `resource.DeleteResponse` | | `tfsdk.ImportResourceStateRequest` | `resource.ImportStateRequest` | | `tfsdk.ImportResourceStateResponse` | `resource.ImportStateResponse` | | `tfsdk.ModifyResourcePlanRequest` | `resource.ModifyPlanRequest` | | `tfsdk.ModifyResourcePlanResponse` | `resource.ModifyPlanResponse` | | `tfsdk.ReadResourceRequest` | `resource.ReadRequest` | | `tfsdk.ReadResourceResponse` | `resource.ReadResponse` | | `tfsdk.Resource` | `resource.Resource` | | `tfsdk.ResourceConfigValidator` | `resource.ConfigValidator` | | `tfsdk.ResourceWithConfigValidators` | `resource.ResourceWithConfigValidators` | | `tfsdk.ResourceWithImportState` | `resource.ResourceWithImportState` | | `tfsdk.ResourceWithModifyPlan` | `resource.ResourceWithModifyPlan` | | `tfsdk.ResourceWithUpgradeState` | `resource.ResourceWithUpgradeState` | | `tfsdk.ResourceWithValidateConfig` | `resource.ResourceWithValidateConfig` | | `tfsdk.UpdateResourceRequest` | `resource.UpdateRequest` | | `tfsdk.UpdateResourceResponse` | `resource.UpdateResponse` | | `tfsdk.UpgradeResourceStateRequest` | `resource.UpgradeStateRequest` | | `tfsdk.UpgradeResourceStateResponse` | `resource.UpgradeStateResponse` | | `tfsdk.ValidateResourceConfigRequest` | `resource.ValidateConfigRequest` | | `tfsdk.ValidateResourceConfigResponse` | `resource.ValidateConfigResponse` |
bflad
added a commit
that referenced
this issue
Jul 29, 2022
…packages Reference: #132 Reference: #365 Reference: #366 Since the framework's initial release, the `tfsdk` Go package has been a monolithic collection of various provider concepts, including but not limited to handling of data sources, providers, resources, schemas, schema data (such as `Config`, `Plan`, and `State`), and various other helpers. For framework maintainers, this monolithic package has made implementations difficult for certain enhancements, such as import cycles. For provider developers, this monolithic package has been difficult to navigate in the Go documentation. This change represents the first major provider coding paradigm shift to colocate related concepts into their own Go packages, starting with new top-level `datasource`, `provider`, and `resource` packages. This particular change and method (no deprecation period) was not desired, but it was unavoidable due to the interconnectedness of the `tfsdk` package and due to the amount of effort it would require to attempt to support both the old and new types. This change is necessary to complete before there are additional code compatibility promises added to this Go module, such as a version 1.0.0 release or release candidate. This type of change is not taken lightly, as it is quite disruptive for existing provider codebases. On the surface, this change may look fairly unbeneficial for provider developers other than the easier discoverability and reduced wordiness, however it is required to unblock other future refactoring and enhancement efforts in the framework. It is unclear at the time of writing whether splitting out the other concepts from the `tfsdk` package, such as schemas, will present the same issues. Regardless, any other major changes will be spread across releases. Provider developers should be able to update their code using find and replace operations using the tables below. To reduce framework maintainer review burden, all code migrations were lift and shift operations while most code and documentation updates were find and replace operations. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ConfigureProviderRequest` | `provider.ConfigureRequest` | | `tfsdk.ConfigureProviderResponse` | `provider.ConfigureResponse` | | `tfsdk.Provider` | `provider.Provider` | | `tfsdk.ProviderConfigValidator` | `provider.ConfigValidator` | | `tfsdk.ProviderWithConfigValidators` | `provider.ProviderWithConfigValidators` | | `tfsdk.ProviderWithProviderMeta` | `provider.ProviderWithMetaSchema` (note naming realignment) | | `tfsdk.ProviderWithValidateConfig` | `provider.ProviderWithValidateConfig` | | `tfsdk.ValidateProviderConfigRequest` | `provider.ValidateConfigRequest` | | `tfsdk.ValidateProviderConfigResponse` | `provider.ValidateConfigResponse` | The `DataSourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `DataSource`. Other data source concept types are migrated to a new `datasource` package. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.DataSourceType` | `provider.DataSourceType` | | Prior tfsdk Package Type | New datasource Package Type | | --- | --- | | `tfsdk.DataSource` | `datasource.DataSource` | | `tfsdk.DataSourceConfigValidator` | `datasource.ConfigValidator` | | `tfsdk.DataSourceWithConfigValidators` | `datasource.DataSourceWithConfigValidators` | | `tfsdk.DataSourceWithValidateConfig` | `datasource.DataSourceWithValidateConfig` | | `tfsdk.ReadDataSourceRequest` | `datasource.ReadRequest` | | `tfsdk.ReadDataSourceResponse` | `datasource.ReadResponse` | | `tfsdk.ValidateDataSourceConfigRequest` | `datasource.ValidateConfigRequest` | | `tfsdk.ValidateDataSourceConfigResponse` | `datasource.ValidateConfigResponse` | The `ResourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `Resource`. Other resource concept types are migrated to a new `resource` package. Additionally, the `tfsdk.ResourceImportStatePassthroughID()` function has been migrated to `resource.ImportStatePassthroughID()`. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ResourceType` | `provider.ResourceType` | | Prior tfsdk Package Type | New resource Package Type | | --- | --- | | `tfsdk.CreateResourceRequest` | `resource.CreateRequest` | | `tfsdk.CreateResourceResponse` | `resource.CreateResponse` | | `tfsdk.DeleteResourceRequest` | `resource.DeleteRequest` | | `tfsdk.DeleteResourceResponse` | `resource.DeleteResponse` | | `tfsdk.ImportResourceStateRequest` | `resource.ImportStateRequest` | | `tfsdk.ImportResourceStateResponse` | `resource.ImportStateResponse` | | `tfsdk.ModifyResourcePlanRequest` | `resource.ModifyPlanRequest` | | `tfsdk.ModifyResourcePlanResponse` | `resource.ModifyPlanResponse` | | `tfsdk.ReadResourceRequest` | `resource.ReadRequest` | | `tfsdk.ReadResourceResponse` | `resource.ReadResponse` | | `tfsdk.Resource` | `resource.Resource` | | `tfsdk.ResourceConfigValidator` | `resource.ConfigValidator` | | `tfsdk.ResourceWithConfigValidators` | `resource.ResourceWithConfigValidators` | | `tfsdk.ResourceWithImportState` | `resource.ResourceWithImportState` | | `tfsdk.ResourceWithModifyPlan` | `resource.ResourceWithModifyPlan` | | `tfsdk.ResourceWithUpgradeState` | `resource.ResourceWithUpgradeState` | | `tfsdk.ResourceWithValidateConfig` | `resource.ResourceWithValidateConfig` | | `tfsdk.UpdateResourceRequest` | `resource.UpdateRequest` | | `tfsdk.UpdateResourceResponse` | `resource.UpdateResponse` | | `tfsdk.UpgradeResourceStateRequest` | `resource.UpgradeStateRequest` | | `tfsdk.UpgradeResourceStateResponse` | `resource.UpgradeStateResponse` | | `tfsdk.ValidateResourceConfigRequest` | `resource.ValidateConfigRequest` | | `tfsdk.ValidateResourceConfigResponse` | `resource.ValidateConfigResponse` |
bflad
added a commit
that referenced
this issue
Aug 1, 2022
…packages Reference: #132 Reference: #365 Reference: #366 Since the framework's initial release, the `tfsdk` Go package has been a monolithic collection of various provider concepts, including but not limited to handling of data sources, providers, resources, schemas, schema data (such as `Config`, `Plan`, and `State`), and various other helpers. For framework maintainers, this monolithic package has made implementations difficult for certain enhancements, such as import cycles. For provider developers, this monolithic package has been difficult to navigate in the Go documentation. This change represents the first major provider coding paradigm shift to colocate related concepts into their own Go packages, starting with new top-level `datasource`, `provider`, and `resource` packages. This particular change and method (no deprecation period) was not desired, but it was unavoidable due to the interconnectedness of the `tfsdk` package and due to the amount of effort it would require to attempt to support both the old and new types. This change is necessary to complete before there are additional code compatibility promises added to this Go module, such as a version 1.0.0 release or release candidate. This type of change is not taken lightly, as it is quite disruptive for existing provider codebases. On the surface, this change may look fairly unbeneficial for provider developers other than the easier discoverability and reduced wordiness, however it is required to unblock other future refactoring and enhancement efforts in the framework. It is unclear at the time of writing whether splitting out the other concepts from the `tfsdk` package, such as schemas, will present the same issues. Regardless, any other major changes will be spread across releases. Provider developers should be able to update their code using find and replace operations using the tables below. To reduce framework maintainer review burden, all code migrations were lift and shift operations while most code and documentation updates were find and replace operations. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ConfigureProviderRequest` | `provider.ConfigureRequest` | | `tfsdk.ConfigureProviderResponse` | `provider.ConfigureResponse` | | `tfsdk.Provider` | `provider.Provider` | | `tfsdk.ProviderConfigValidator` | `provider.ConfigValidator` | | `tfsdk.ProviderWithConfigValidators` | `provider.ProviderWithConfigValidators` | | `tfsdk.ProviderWithProviderMeta` | `provider.ProviderWithMetaSchema` (note naming realignment) | | `tfsdk.ProviderWithValidateConfig` | `provider.ProviderWithValidateConfig` | | `tfsdk.ValidateProviderConfigRequest` | `provider.ValidateConfigRequest` | | `tfsdk.ValidateProviderConfigResponse` | `provider.ValidateConfigResponse` | The `DataSourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `DataSource`. Other data source concept types are migrated to a new `datasource` package. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.DataSourceType` | `provider.DataSourceType` | | Prior tfsdk Package Type | New datasource Package Type | | --- | --- | | `tfsdk.DataSource` | `datasource.DataSource` | | `tfsdk.DataSourceConfigValidator` | `datasource.ConfigValidator` | | `tfsdk.DataSourceWithConfigValidators` | `datasource.DataSourceWithConfigValidators` | | `tfsdk.DataSourceWithValidateConfig` | `datasource.DataSourceWithValidateConfig` | | `tfsdk.ReadDataSourceRequest` | `datasource.ReadRequest` | | `tfsdk.ReadDataSourceResponse` | `datasource.ReadResponse` | | `tfsdk.ValidateDataSourceConfigRequest` | `datasource.ValidateConfigRequest` | | `tfsdk.ValidateDataSourceConfigResponse` | `datasource.ValidateConfigResponse` | The `ResourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `Resource`. Other resource concept types are migrated to a new `resource` package. Additionally, the `tfsdk.ResourceImportStatePassthroughID()` function has been migrated to `resource.ImportStatePassthroughID()`. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ResourceType` | `provider.ResourceType` | | Prior tfsdk Package Type | New resource Package Type | | --- | --- | | `tfsdk.CreateResourceRequest` | `resource.CreateRequest` | | `tfsdk.CreateResourceResponse` | `resource.CreateResponse` | | `tfsdk.DeleteResourceRequest` | `resource.DeleteRequest` | | `tfsdk.DeleteResourceResponse` | `resource.DeleteResponse` | | `tfsdk.ImportResourceStateRequest` | `resource.ImportStateRequest` | | `tfsdk.ImportResourceStateResponse` | `resource.ImportStateResponse` | | `tfsdk.ModifyResourcePlanRequest` | `resource.ModifyPlanRequest` | | `tfsdk.ModifyResourcePlanResponse` | `resource.ModifyPlanResponse` | | `tfsdk.ReadResourceRequest` | `resource.ReadRequest` | | `tfsdk.ReadResourceResponse` | `resource.ReadResponse` | | `tfsdk.Resource` | `resource.Resource` | | `tfsdk.ResourceConfigValidator` | `resource.ConfigValidator` | | `tfsdk.ResourceWithConfigValidators` | `resource.ResourceWithConfigValidators` | | `tfsdk.ResourceWithImportState` | `resource.ResourceWithImportState` | | `tfsdk.ResourceWithModifyPlan` | `resource.ResourceWithModifyPlan` | | `tfsdk.ResourceWithUpgradeState` | `resource.ResourceWithUpgradeState` | | `tfsdk.ResourceWithValidateConfig` | `resource.ResourceWithValidateConfig` | | `tfsdk.UpdateResourceRequest` | `resource.UpdateRequest` | | `tfsdk.UpdateResourceResponse` | `resource.UpdateResponse` | | `tfsdk.UpgradeResourceStateRequest` | `resource.UpgradeStateRequest` | | `tfsdk.UpgradeResourceStateResponse` | `resource.UpgradeStateResponse` | | `tfsdk.ValidateResourceConfigRequest` | `resource.ValidateConfigRequest` | | `tfsdk.ValidateResourceConfigResponse` | `resource.ValidateConfigResponse` |
bflad
added a commit
that referenced
this issue
Aug 2, 2022
…packages (#432) Reference: #132 Reference: #365 Reference: #366 Since the framework's initial release, the `tfsdk` Go package has been a monolithic collection of various provider concepts, including but not limited to handling of data sources, providers, resources, schemas, schema data (such as `Config`, `Plan`, and `State`), and various other helpers. For framework maintainers, this monolithic package has made implementations difficult for certain enhancements, such as import cycles. For provider developers, this monolithic package has been difficult to navigate in the Go documentation. This change represents the first major provider coding paradigm shift to colocate related concepts into their own Go packages, starting with new top-level `datasource`, `provider`, and `resource` packages. This particular change and method (no deprecation period) was not desired, but it was unavoidable due to the interconnectedness of the `tfsdk` package and due to the amount of effort it would require to attempt to support both the old and new types. This change is necessary to complete before there are additional code compatibility promises added to this Go module, such as a version 1.0.0 release or release candidate. This type of change is not taken lightly, as it is quite disruptive for existing provider codebases. On the surface, this change may look fairly unbeneficial for provider developers other than the easier discoverability and reduced wordiness, however it is required to unblock other future refactoring and enhancement efforts in the framework. It is unclear at the time of writing whether splitting out the other concepts from the `tfsdk` package, such as schemas, will present the same issues. Regardless, any other major changes will be spread across releases. Provider developers should be able to update their code using find and replace operations using the tables below. To reduce framework maintainer review burden, all code migrations were lift and shift operations while most code and documentation updates were find and replace operations. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ConfigureProviderRequest` | `provider.ConfigureRequest` | | `tfsdk.ConfigureProviderResponse` | `provider.ConfigureResponse` | | `tfsdk.Provider` | `provider.Provider` | | `tfsdk.ProviderConfigValidator` | `provider.ConfigValidator` | | `tfsdk.ProviderWithConfigValidators` | `provider.ProviderWithConfigValidators` | | `tfsdk.ProviderWithProviderMeta` | `provider.ProviderWithMetaSchema` (note naming realignment) | | `tfsdk.ProviderWithValidateConfig` | `provider.ProviderWithValidateConfig` | | `tfsdk.ValidateProviderConfigRequest` | `provider.ValidateConfigRequest` | | `tfsdk.ValidateProviderConfigResponse` | `provider.ValidateConfigResponse` | The `DataSourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `DataSource`. Other data source concept types are migrated to a new `datasource` package. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.DataSourceType` | `provider.DataSourceType` | | Prior tfsdk Package Type | New datasource Package Type | | --- | --- | | `tfsdk.DataSource` | `datasource.DataSource` | | `tfsdk.DataSourceConfigValidator` | `datasource.ConfigValidator` | | `tfsdk.DataSourceWithConfigValidators` | `datasource.DataSourceWithConfigValidators` | | `tfsdk.DataSourceWithValidateConfig` | `datasource.DataSourceWithValidateConfig` | | `tfsdk.ReadDataSourceRequest` | `datasource.ReadRequest` | | `tfsdk.ReadDataSourceResponse` | `datasource.ReadResponse` | | `tfsdk.ValidateDataSourceConfigRequest` | `datasource.ValidateConfigRequest` | | `tfsdk.ValidateDataSourceConfigResponse` | `datasource.ValidateConfigResponse` | The `ResourceType` abstraction migrates to the `provider` package since it relates to data that must be populated before the provider is configured as well as being passed the `Provider` interface, which can be converted into a concrete Go type when creating a `Resource`. Other resource concept types are migrated to a new `resource` package. Additionally, the `tfsdk.ResourceImportStatePassthroughID()` function has been migrated to `resource.ImportStatePassthroughID()`. | Prior tfsdk Package Type | New provider Package Type | | --- | --- | | `tfsdk.ResourceType` | `provider.ResourceType` | | Prior tfsdk Package Type | New resource Package Type | | --- | --- | | `tfsdk.CreateResourceRequest` | `resource.CreateRequest` | | `tfsdk.CreateResourceResponse` | `resource.CreateResponse` | | `tfsdk.DeleteResourceRequest` | `resource.DeleteRequest` | | `tfsdk.DeleteResourceResponse` | `resource.DeleteResponse` | | `tfsdk.ImportResourceStateRequest` | `resource.ImportStateRequest` | | `tfsdk.ImportResourceStateResponse` | `resource.ImportStateResponse` | | `tfsdk.ModifyResourcePlanRequest` | `resource.ModifyPlanRequest` | | `tfsdk.ModifyResourcePlanResponse` | `resource.ModifyPlanResponse` | | `tfsdk.ReadResourceRequest` | `resource.ReadRequest` | | `tfsdk.ReadResourceResponse` | `resource.ReadResponse` | | `tfsdk.Resource` | `resource.Resource` | | `tfsdk.ResourceConfigValidator` | `resource.ConfigValidator` | | `tfsdk.ResourceWithConfigValidators` | `resource.ResourceWithConfigValidators` | | `tfsdk.ResourceWithImportState` | `resource.ResourceWithImportState` | | `tfsdk.ResourceWithModifyPlan` | `resource.ResourceWithModifyPlan` | | `tfsdk.ResourceWithUpgradeState` | `resource.ResourceWithUpgradeState` | | `tfsdk.ResourceWithValidateConfig` | `resource.ResourceWithValidateConfig` | | `tfsdk.UpdateResourceRequest` | `resource.UpdateRequest` | | `tfsdk.UpdateResourceResponse` | `resource.UpdateResponse` | | `tfsdk.UpgradeResourceStateRequest` | `resource.UpgradeStateRequest` | | `tfsdk.UpgradeResourceStateResponse` | `resource.UpgradeStateResponse` | | `tfsdk.ValidateResourceConfigRequest` | `resource.ValidateConfigRequest` | | `tfsdk.ValidateResourceConfigResponse` | `resource.ValidateConfigResponse` |
bflad
added a commit
that referenced
this issue
Aug 2, 2022
…ateForUnknown()` plan modifier functions to the `resource` package Reference: #132 Reference: #365 Reference: #366 Reference: #432 Plan modification in the framework is a concept that only applies to managed resources via the protocol `PlanResourceChange` RPC. Following the migration of other `tfsdk` package types into separate `datasource`, `provider`, and `resource` packages, this change migrates the `RequiresReplace()`, `RequiresReplaceIf()` and `UseStateForUnknown()` plan modifier functions into the `resource` package. This change should be bundled in the same release as the package refactoring since it is similar in nature. This change has two immediate benefits: - Aligning the Go package placement tof these functions o hint to provider developers that these are only intended for managed resources. - For future refactoring this removes additional schema-based code imports from the `tfsdk` package, which could enable refactoring the schema logic into internal packages with potentially less breaking changes for provider developers by removing a source of import cycles. Provider developers should be able to update their code using find and replace operations using the table below: | Prior tfsdk Package Function | New resource Package Function | | --- | --- | | `tfsdk.RequiresReplace` | `resource.RequiresReplace` | | `tfsdk.RequiresReplaceIf` | `resource.RequiresReplaceIf` | | `tfsdk.UseStateForUnknown` | `resource.UseStateForUnknown` | To reduce framework maintainer review burden, this code migrations was primarily a lift and shift operation while most code and documentation updates were find and replace operations. The modifier types were unexported as exposing them should not be beneficial for provider developers and should help reduce the Go documentation surface area. The plan modifier unit testing was updated to use a `_test` package so it is verifying only exported functionality.
bflad
added a commit
that referenced
this issue
Aug 2, 2022
…ateForUnknown()` plan modifier functions to the `resource` package (#434) Reference: #132 Reference: #365 Reference: #366 Reference: #432 Plan modification in the framework is a concept that only applies to managed resources via the protocol `PlanResourceChange` RPC. Following the migration of other `tfsdk` package types into separate `datasource`, `provider`, and `resource` packages, this change migrates the `RequiresReplace()`, `RequiresReplaceIf()` and `UseStateForUnknown()` plan modifier functions into the `resource` package. This change should be bundled in the same release as the package refactoring since it is similar in nature. This change has two immediate benefits: - Aligning the Go package placement tof these functions o hint to provider developers that these are only intended for managed resources. - For future refactoring this removes additional schema-based code imports from the `tfsdk` package, which could enable refactoring the schema logic into internal packages with potentially less breaking changes for provider developers by removing a source of import cycles. Provider developers should be able to update their code using find and replace operations using the table below: | Prior tfsdk Package Function | New resource Package Function | | --- | --- | | `tfsdk.RequiresReplace` | `resource.RequiresReplace` | | `tfsdk.RequiresReplaceIf` | `resource.RequiresReplaceIf` | | `tfsdk.UseStateForUnknown` | `resource.UseStateForUnknown` | To reduce framework maintainer review burden, this code migrations was primarily a lift and shift operation while most code and documentation updates were find and replace operations. The modifier types were unexported as exposing them should not be beneficial for provider developers and should help reduce the Go documentation surface area. The plan modifier unit testing was updated to use a `_test` package so it is verifying only exported functionality.
This was referenced Aug 12, 2022
bflad
added a commit
that referenced
this issue
Aug 29, 2022
…cription Reference: #365 Reference: #366 This change represents another evolutionary step to move away from `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` types directly, where the temporarily duplicated logic in `internal/fwserver` which worked directly with those types is replaced with the shared data implementation.
bflad
added a commit
that referenced
this issue
Aug 30, 2022
…cription (#464) Reference: #365 Reference: #366 This change represents another evolutionary step to move away from `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` types directly, where the temporarily duplicated logic in `internal/fwserver` which worked directly with those types is replaced with the shared data implementation.
iwarapter
pushed a commit
to iwarapter/terraform-plugin-framework
that referenced
this issue
Sep 4, 2022
Reference: hashicorp#366 This change creates the initial `internal/fwschemadata` package, which will hold the shared implementation details of schema-based data, such as the existing `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` types and potentially other implementations in the future. This refactoring will be gradual over time to reduce review burden and should not introduce provider developer changes until potentially at the end of the refactoring. The main interaction point will be the `Data` type, which currently contains the schema and terraform-plugin-go value information. This type may be expanded in the future to support diagnostic message customization (e.g. denoting the data is a "configuration") and eventually could support value migration to a framework native type (e.g. `types.Object`). The initial functionality refactored is: - Fetch and reflect entire value (`Get()` method) - Path existence (`PathExists()` method) - Path matching (`PathMatches()` method) - terraform-plugin-go value extraction at a given terraform-plugin-go path (`TerraformValueAtTerraformPath()` method) The unit testing is meant to be more exhaustive than what was previously performed in the `tfsdk` package.
iwarapter
pushed a commit
to iwarapter/terraform-plugin-framework
that referenced
this issue
Sep 4, 2022
…ue logic (hashicorp#453) Reference: hashicorp#366 This change continues the migration of `tfsdk.Config`/`tfsdk.Plan`/`tfsdk.State` type logic into the `internal/fwschemadata` package `Data` type, so the implementation is shared and to potentially introduce other implementations.
iwarapter
pushed a commit
to iwarapter/terraform-plugin-framework
that referenced
this issue
Sep 4, 2022
…icorp#454) Reference: hashicorp#366 This change continues the migration of `tfsdk.Config`/`tfsdk.Plan`/`tfsdk.State` type logic into the `internal/fwschemadata` package `Data` type, so the implementation is shared and to potentially introduce other implementations.
|
This |
|
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.
Module version
Use-cases
While working through some of the framework server refactoring as part of #215, it was necessary to extract some of the
tfsdk.Config,tfsdk.Plan, andtfsdk.Stateunexported methods into temporary functions within theinternal/fwserverpackage so they did not become part of the publictfsdkAPIs. For example,ConfigGetAttributeValue(). This highlighted that a larger portion of the "schema data" handling would benefit as being in internal packages and colocated again, rather than splitting the logic across packages, while still exporting provider developer functionality only as necessary intfsdkor some other "public" package.Proposal
To be written up, but a current thought is that there should be an
internal/schemadataor similar package which contains the full framework schema-based data handling, whiletfsdkor another package merely exposes anything that should be in the public API. Ideally, there would be a single implementation for readable and writable data that is shared across the Config/Plan/State implementations.References
The text was updated successfully, but these errors were encountered: