Skip to content

schema: Revisit LiteralType.SkipComplexTypes workaround #271

Open
@radeksimko

Description

@radeksimko

Context

As part of #232 in order to avoid duplicate completion we decided to introduce two "toggle" fields, such that we can nest and reuse LiteralType and AnyExpression constraints without those negative side effects.

// SkipLiteralComplexTypes avoids descending into complex literal types, such as {} and [].
// It might be required when AnyExpression is used in OneOf to avoid duplicates.
SkipLiteralComplexTypes bool

// SkipComplexTypes avoids descending into complex literal types, such as {} and [].
// It might be required when LiteralType is used in OneOf to avoid duplicates.
SkipComplexTypes bool

We implemented this as the easiest way of addressing the problem as we were nearing the planned release date.

However, this introduced new API surface which should ideally in practice remain an implementation detail. i.e. a schema author shouldn't have to be concerned about this detail and should have some easier way of expressing e.g. "list or any expression evaluating to list" and similar constraints.

i.e. this does not make for the most readable code

Constraint: schema.OneOf{
	schema.AnyExpression{OfType: cty.Map(cty.String), SkipLiteralComplexTypes: true},
	schema.Map{
		Elem: schema.AnyExpression{OfType: cty.String},
	},
},

Notes

One additional complexity to consider is that there's certain metadata in complex types which we should be surfacing somewhere, esp. in completion and hover and this metadata often applies not just to the literal expression but to any expression which - when evaluated - complies with the constraint.

For example:

  • List/Set - Description, MinItems, MaxItems
  • Tuple - Description
  • Map - Description, Name, MinItems, MaxItems
  • Object - Description, Name

This suggests that we could re-implement this such that e.g. schema.Map complies with any interpretation of a map (including references or function calls), and leave AnyExpression only for situations where the extra metadata isn't needed.

Proposal

  • Explore other ways the same constraint could be expressed in the schema
  • Look at other products (other than Terraform) to understand their needs in this area

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions