Hi,
In TF11 join("",resource.name.*.attr) was a common way to handle values from conditional resources/resources with count=0.
Is there a better way in TF12?
Is it better to use for expressions instead of count to make conditional resources?
TIA
Hi,
In TF11 join("",resource.name.*.attr) was a common way to handle values from conditional resources/resources with count=0.
Is there a better way in TF12?
Is it better to use for expressions instead of count to make conditional resources?
TIA
For this sort of thing I would suggest using whatever expression type makes it clearest to a future reader what your intent is. The join("", resource.name.*.attr)
form doesnât really live up to that: a future reader who is not an expert in Terraform workarounds would be unlikely to be able to infer that the goal here is to either produce the value from a single .attr
or to produce an empty string.
This is a subjective style thing, so I donât think thereâs a single âright answerâ, but I usually prefer to write a conditional expression because that should make it clear to a future reader that a decision is being made, exactly what that decision is, and what values will result from each outcome of the decision:
length(resource.name) > 0 ? resource.name[0].attr : ""
The above is hopefully relatively clear to anyone who is familiar with these C-style operators:
resource.name
has at least one item..attr
value from the first item.I know from experience helping other people that some folks prioritize brevity, so Iâd understand if you consider the above to be âtoo longâ or similar. There are lots of different ways to use the Terraform language features to make it shorter if thatâs your goal, though I donât have any prepared examples to share and Iâd always still caution to try to make sure that a future reader wonât need to be a Terraform language expert in order to understand it.
I agree with preferring the more explicit code and using the conditional does that.
It would be great, though, to have more options along the line of lookup(resource.name, 0, "")
or default(resource.name[0],"")
to make this more elegant? I guess I was hoping there was something I was missing there.
One thing that worries me about both the conditional and lookup with index (if it existed) is that they hide an edge case where resource.name[*]
unexpectedly has more than one element. Using join()
actually helps to raise that mistake to the surface when it results in some ugly value.
Alternatively, any plans to support âifâ on resources instead of count=1:0 might be the holy grail?
I just ran across the new try()
syntax.
The docs seem fairly against using try()
outside the limited scope of normalizing values inside locals. Would it cause problems to adopt it for this use case as well, ie. try(resource.name[0],"")
?
Hi @yruss972,
As youâve seen, thereâs no technical reason not to use try
in the way youâve described. As always, we have to make a subjective decision about whether the result is clear enough to a hypothetical future reader.
The try
function hasnât yet been around long enough for me to have developed a sense for how intuitive folks tend to find it when they encounter it for the first time âin the wildâ rather than in the docs, and (unlike the conditional operator) it doesnât have analogous features in other languages that readers might bring their experience/assumptions about, so Iâd be inclined to use try
with care for now but perhaps over time weâll learn that itâs understandable enough to the non-expert reader that the recommendations in the documentation could be loosened.