Module version
Use-cases
Provider developers may wish to develop generic "top level" schema data based configuration validators that satisfy all the following interfaces:
- tfsdk.DataSourceConfigValidator
- tfsdk.ProviderConfigValidator
- tfsdk.ResourceConfigValidator
Such as these:
These *ConfigValidator interfaces were originally split during the initial validation implementation to allow separate feature handling, should the protocol individually change over time for one or more of the Validate*Config RPCs. I think the split use cases is very valid and follows the original design principles of this framework, however I made a simple mistake in the actual code for the interfaces, where they each use the same Validate() method name with differently typed parameters. Oops. They should use different method names so all three can be implemented, if desired. The validator developer can choose to share the implementation details across them to reduce code, however that is outside the scope of the framework anyways.
Attempted Solutions
Individual data source, provider, and resource configuration validators. 😢
Proposal
Adjust the interfaces slightly from:
type DataSourceConfigValidator interface {
// ... other fields ...
Validate(context.Context, ValidateDataSourceConfigRequest, *ValidateDataSourceConfigResponse)
}
type ProviderConfigValidator interface {
// ... other fields ...
Validate(context.Context, ValidateProviderConfigRequest, *ValidateProviderConfigResponse)
}
type ResourceConfigValidator interface {
// ... other fields ...
Validate(context.Context, ValidateResourceConfigRequest, *ValidateResourceConfigResponse)
}To:
type DataSourceConfigValidator interface {
// ... other fields ...
ValidateDataSource(context.Context, ValidateDataSourceConfigRequest, *ValidateDataSourceConfigResponse)
}
type ProviderConfigValidator interface {
// ... other fields ...
ValidateProvider(context.Context, ValidateProviderConfigRequest, *ValidateProviderConfigResponse)
}
type ResourceConfigValidator interface {
// ... other fields ...
ValidateResource(context.Context, ValidateResourceConfigRequest, *ValidateResourceConfigResponse)
}One potential consideration here is a separate breaking change to refactor data source, provider, and resource specific types into their own packages, but I think this change can be made beforehand without too much repercussions given that these are likely rare in the wild at the moment (as compared to attribute validators) and when that refactoring potentially happens it can just be a breaking change of the type name itself while keeping the newly specific Validate* method names.
References
Module version
Use-cases
Provider developers may wish to develop generic "top level" schema data based configuration validators that satisfy all the following interfaces:
Such as these:
These
*ConfigValidatorinterfaces were originally split during the initial validation implementation to allow separate feature handling, should the protocol individually change over time for one or more of theValidate*ConfigRPCs. I think the split use cases is very valid and follows the original design principles of this framework, however I made a simple mistake in the actual code for the interfaces, where they each use the sameValidate()method name with differently typed parameters. Oops. They should use different method names so all three can be implemented, if desired. The validator developer can choose to share the implementation details across them to reduce code, however that is outside the scope of the framework anyways.Attempted Solutions
Individual data source, provider, and resource configuration validators. 😢
Proposal
Adjust the interfaces slightly from:
To:
One potential consideration here is a separate breaking change to refactor data source, provider, and resource specific types into their own packages, but I think this change can be made beforehand without too much repercussions given that these are likely rare in the wild at the moment (as compared to attribute validators) and when that refactoring potentially happens it can just be a breaking change of the type name itself while keeping the newly specific
Validate*method names.References
schemavalidatorpackage terraform-plugin-framework-validators#32 (review)