Hi @bschaeffer,
Inside a set, elements are identified by their own content alone, so there isn’t really any concept of editing an existing object: there is no stable identifier to use to determine which object was changed. Removing the existing object and adding a new one is therefore the correct interpretation of this change.
The other option available todayis schema.TypeList
, which uses the position of the item in the sequence as the identifier, and thus allows recognizing the difference between adding a new item and editing an existing one by correlating by index.
It sounds like in your system the name
argument is a unique key and so you want to use that argument as the unique key to recognize objects. As you’ve seen, that isn’t currently possible for schema.TypeMap
with the current SDK, although Terraform Core itself (since Terraform v0.12) does support a structure like this, so I understand it’s frustrating that the SDK is not exposing that functionality today.
A block backed by a map, were it possible to represent in the SDK, would expect a syntax like the following to make it clear what the unique identifier for each block is:
role "owner" {
description = "Owner of foo"
}
This functionality is available via the lower-level utility library terraform-plugin-go
, but that is at a considerably less convenient level of abstraction since it’s really just a thin wrapper around Terraform’s wire protocol. There is a replacement for
terraform-plugin-sdk
coming, named terraform-plugin-framework
, but at the time I’m writing this it’s only in the design phase and isn’t usable yet.
Given all of this, I would suggest continuing with TypeSet
for now and accepting the non-ideal diffs as a cosmetic quirk that won’t otherwise affect the behavior – as the developer of the resource type, you can choose to implement it as an update-in-place if you wish, regardless of what the rendered plan might show. Later you might be able to improve on this using the new SDK framework, but it’ll still be some time before that is in a stable, usable state.