-
Notifications
You must be signed in to change notification settings - Fork 95
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
tfsdk: Consider Caching Provider Defined Resources/Data Sources in Server #299
Comments
Similar caching could also be done for Provider, DataSourceType, and ResourceType GetSchema calls. |
… and toproto6 Reference: #215 One particular quirk that this implementation shows is that it is not entirely possible to avoid working with `tfsdk`/`fwserver` bits in `proto6server` as the current data types within the framework (`Config`, `Plan`, `State`) require the `Schema` so data can be appropriately converted from the protocol to the framework. To support this effort and prevent repetitively executing the provider defined `GetSchema` method, a `fwserver` method is introduced that caches the `Schema` and `Diagnostics` results on first use. This methodology can also be applied in the future to resolve #299.
(Commit message wording accidentally closed this) |
…r, and toproto6 Reference: #215 Reference: #299 This introduces framework server caching for data source types and schemas, similar to the provider schema cache, which is needed with other data source RPCs. The same methodology will be applied for resource types and schemas, when the `ValidateResourceConfig` RPC is migrated.
…r, and toproto6 (#324) Reference: #215 Reference: #299 This introduces framework server caching for data source types and schemas, similar to the provider schema cache, which is needed with other data source RPCs. The same methodology will be applied for resource types and schemas, when the `ValidateResourceConfig` RPC is migrated.
…move intermediate Provider field Reference: #215 Reference: #299 This completes the migration to the cached data source and resource schema/type handling in the new `internal/fwserver` package. This also removes the previous `Provider` field so that implementation detail is now wholly within the `internal/fwserver` to remove any confusion.
…move intermediate Provider field Reference: #215 Reference: #299 This completes the migration to the cached data source and resource schema/type handling in the new `internal/fwserver` package. This also removes the previous `Provider` field so that implementation detail is now wholly within the `internal/fwserver` to remove any confusion.
…move intermediate Provider field (#333) Reference: #215 Reference: #299 This completes the migration to the cached data source and resource schema/type handling in the new `internal/fwserver` package. This also removes the previous `Provider` field so that implementation detail is now wholly within the `internal/fwserver` to remove any confusion.
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
Use-cases
The current provider server logic always calls back into the provider defined
GetResources()
andGetDataSources()
methods when trying to find eachResourceType
orDataSourceType
associated with every RPC. While not a biggest performance deal, it does mean that it is repeatedly fetching the maps and executing any provider logic (if any). Terraform CLI and the framework currently expect the type mapping to be consistent for providers afterGetProviderSchema
. The server could cache these maps on first use.Proposal
dataSourceTypes map[string]DataSourceType
andresourceTypes map[string]ResourceType
fields to theserver
type(*server).GetProviderSchema()
, sets.dataSourceTypes = dataSourceSchemas
ands.resourceTypes = resourceSchemas
(*server).getDataSourceType()
and(*server).getResourceType()
methods to checks.dataSourceTypes
ands.resourceTypes
fields instead of calling the provider definedGetDataSources()
andGetResources()
methodsThe text was updated successfully, but these errors were encountered: