Attribute validators ensure that attributes do or do not contain specific values. You can use predefined validators for
many use cases, or implement custom validators. Refer to Schemas - Validators in
the Framework documentation for details. Refer to the
Attributes - Custom Validators page in this guide to learn how to
implement custom validators.
This page explains how to migrate a predefined validator from SDKv2 to the Framework.
In SDKv2, the ConflictsWith, ExactlyOneOf, AtLeastOneOf, and RequiredWith fields on an attribute's
schema.Schema struct perform predefined validations on the list of attributes set for these fields.
In the Framework, you implement either type of validation by setting the Validators field on the tfsdk.Attribute
struct with types that satisfy the tfsdk.AttributeValidator interface. Validators that perform the same checks as the
predefined validators in SDKv2 are
available for the Framework. If the predefined
validators do not meet your needs, you must define
custom validators.
Configuration validators can also be defined for
providers,
resources and
data sources by
implementing ProviderWithConfigValidators, ResourceWithConfigValidators, and DataSourceWithConfigValidators
interfaces, respectively.
Remember the following details when migrating from SDKv2 to the Framework.
In SDKv2, ValidateDiagFunc is a field on schema.Schema that you can use to define validation functions. In SDKv2,
there are also built-in validations. For example, ConflictsWith is a field on the schema.Schema struct in SDKv2. In
the Framework, Validators is a field on each tfsdk.Attribute struct.
Validators replicating the behavior of ConflictsWith, ExactlyOneOf, AtLeastOneOf, and RequiredWith in SDKv2 are
available for the Framework:
The following example from the provider.go file shows the implementation of the ConflictsWith field on the
provider's proxy block's url attribute. This validator checks that the provider does not use the url attribute
when the proxy's url is set through the environment. The example also uses the RequiredWith field to ensure that the
password attribute is configured when username is, and vice-versa.
The following shows the same section of provider code after the migration.
This code implements the ConflictsWith and AlsoRequires validators with the Framework. The validators are configured
via the Validators field of the provider's proxy block's attribute schema.