objchange

Documentation

Overview

Package objchange deals with the business logic of taking a prior state value and a config value and producing a proposed new merged value, along with other related rules in this domain.

Index

• func AssertObjectCompatible(schema *configschema.Block, planned, actual cty.Value) []error
• func LongestCommonSubsequence(xs, ys []cty.Value) []cty.Value
• func ProposedNewObject(schema *configschema.Block, prior, config cty.Value) cty.Value

Functions

func AssertObjectCompatible

func AssertObjectCompatible(schema *configschema.Block, planned, actual cty.Value) []error

AssertObjectCompatible checks whether the given "actual" value is a valid completion of the possibly-partially-unknown "planned" value.

This means that any known leaf value in "planned" must be equal to the corresponding value in "actual", and various other similar constraints.

Any inconsistencies are reported by returning a non-zero number of errors. These errors are usually (but not necessarily) cty.PathError values referring to a particular nested value within the "actual" value.

The two values must have types that conform to the given schema's implied type, or this function will panic.

func LongestCommonSubsequence

func LongestCommonSubsequence(xs, ys []cty.Value) []cty.Value

LongestCommonSubsequence finds a sequence of values that are common to both x and y, with the same relative ordering as in both collections. This result is useful as a first step towards computing a diff showing added/removed elements in a sequence.

The approached used here is a "naive" one, assuming that both xs and ys will generally be small in most reasonable Terraform configurations. For larger lists the time/space usage may be sub-optimal.

A pair of lists may have multiple longest common subsequences. In that case, the one selected by this function is undefined.

func ProposedNewObject

func ProposedNewObject(schema *configschema.Block, prior, config cty.Value) cty.Value

ProposedNewObject constructs a proposed new object value by combining the computed attribute values from "prior" with the configured attribute values from "config".

Both value must conform to the given schema's implied type, or this function will panic.

The prior value must be wholly known, but the config value may be unknown or have nested unknown values.

The merging of the two objects includes the attributes of any nested blocks, which will be correlated in a manner appropriate for their nesting mode. Note in particular that the correlation for blocks backed by sets is a heuristic based on matching non-computed attribute values and so it may produce strange results with more "extreme" cases, such as a nested set block where _all_ attributes are computed.