A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.hashicorp.com/terraform/plugin/framework/handling-data/attributes/set-nested below:

Set nested attributes | Terraform

Set nested attributes store a unique, unordered collection of nested objects. Values are represented by a set type in the framework, containing elements of object type.

In this Terraform configuration example, a set nested attribute named example_attribute is set to the unordered object values of attr to "one" and attr to "two":

resource "examplecloud_thing" "example" {
  example_attribute = [
    {
        attr = "one"
    },
    {
        attr = "two"
    },
  ]
}

Use one of the following attribute types to directly add a set nested value to a schema or nested attribute type:

The NestedObject field must be defined, which represents the object value type of every element of the set.

In this example, a resource schema defines a top level required set nested attribute named example_attribute with a required string attribute named attr:

func (r ThingResource) Schema(ctx context.Context, req resource.SchemaRequest, resp *resource.SchemaResponse) {
    resp.Schema = schema.Schema{
        Attributes: map[string]schema.Attribute{
            "example_attribute": schema.SetNestedAttribute{
                NestedObject: schema.NestedAttributeObject{
                    Attributes: map[string]schema.Attribute{
                        "attr": schema.StringAttribute{
                            Required: true,
                            // ... potentially other fields ...
                        },
                    },
                },
                Required: true,
                // ... potentially other fields ...
            },
            // ... potentially other attributes ...
        },
    }
}

Its value type would be represented as a types.Set of types.Object where the types.Object is a mapping of attr to types.String.

A nested attribute type may itself contain further collection or nested attribute types, if necessary.

In this example, a resource schema defines a top level required set nested attribute named example_attribute with a required list of strings attribute named attr1 and an optional single nested attribute named attr2:

func (r ThingResource) Schema(ctx context.Context, req resource.SchemaRequest, resp *resource.SchemaResponse) {
    resp.Schema = schema.Schema{
        Attributes: map[string]schema.Attribute{
            "example_attribute": schema.SetNestedAttribute{
                NestedObject: schema.NestedAttributeObject{
                    Attributes: map[string]schema.Attribute{
                        "attr1": schema.ListAttribute{
                            ElementType: types.StringType,
                            Required: true,
                            // ... potentially other fields ...
                        },
                        "attr2": schema.SingleNestedAttribute{
                            Attributes: map[string]schema.Attribute{ /* ... */ },
                            Optional: true,
                            // ... potentially other fields ...
                        },
                    },
                },
                Required: true,
                // ... potentially other fields ...
            },
            // ... potentially other attributes ...
        },
    }
}

Its value type would be represented as a types.Set of types.Object where the types.Object is a mapping of attr1 to types.List of types.String and attr2 to types.Object.

Configurability

Note

Only the set nested attribute itself is defined by the schema.SetNestedAttribute configurability fields. Nested attributes must define their own configurability fields within each attribute definition.

At least one of the Computed, Optional, or Required fields must be set to true. This defines how Terraform and the framework should expect data to set, whether the value is from the practitioner configuration or from the provider logic, such as API response value.

The acceptable behaviors of these configurability options are:

Custom Types

You may want to build your own attribute value and type implementations to allow your provider to combine validation, description, and plan customization behaviors into a reusable bundle. This helps avoid duplication or reimplementation and ensures consistency. These implementations use the CustomType field in the attribute type.

Refer to Custom Types for further details on creating provider-defined types and values.

Deprecation

Set the DeprecationMessage field to a practitioner-focused message for how to handle the deprecation. The framework will automatically raise a warning diagnostic with this message if the practitioner configuration contains a known value for the attribute. Terraform version 1.2.7 and later will raise a warning diagnostic in certain scenarios if the deprecated attribute value is referenced elsewhere in a practitioner configuration. The framework deprecations documentation fully describes the recommended practices for deprecating an attribute or resource.

Some practitioner-focused examples of a deprecation message include:

Description

The framework provides two description fields, Description and MarkdownDescription, which various tools use to show additional information about an attribute and its intended purpose. This includes, but is not limited to, terraform-plugin-docs for automated provider documentation generation and terraform-ls for Terraform configuration editor integrations.

Plan Modification

Tip

Only managed resources implement this concept.

The framework provides two plan modification fields for managed resource attributes, Default and PlanModifiers, which define resource and attribute value planning behaviors. The resource default and plan modification documentation covers these features more in-depth.

Common Use Case Plan Modification

The setdefault package defines common use case Default implementations:

The setplanmodifier package defines common use case PlanModifiers implementations:

Sensitive

Set the Sensitive field if the attribute value should always be considered sensitive data. In Terraform, this will generally mask the value in practitioner output. This setting cannot be conditionally set and does not impact how data is stored in the state.

Validation

Set the Validators field to define validation. This validation logic is ran in addition to any validation contained within a custom type.

Common Use Case Validators

HashiCorp provides the additional terraform-plugin-framework-validators Go module which contains validation logic for common use cases. The setvalidator package within that module has set attribute validators such as defining conflicting attributes.

The accessing values documentation covers general methods for reading schema (configuration, plan, and state) data, which is necessary before accessing an attribute value directly. The set type documentation covers methods for interacting with the attribute value itself.

The set type documentation covers methods for creating or setting the appropriate value. The writing data documentation covers general methods for writing schema (plan and state) data, which is necessary afterwards.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4