[Prototype] How to support complex attributes in logs/events? (Option C) #6960
+826
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another half-baked option.
This is basically Option A, but instead of reusing the
Attributes
class as the property bag for nested attributes, it introduces new typesComplexAttribute
/ComplexAttributeBuilder
/ComplexAttributeKey
which are just copies ofAttributes
/AttributesBuilder
/AttributesKey
.The disadvantage of this option is obviously the copy-pasting.
The advantage of this option is that it is a bit more explicit for users (and so probably a bit less confusing than reusing the top-level Attributes bag to represent complex attributes).
Note: I'm using the term "complex attributes" to mean map-valued attributes. I will see if this (or some other) term can be agreed on in specification / semconv.
Another naming option could be:
MapAttribute
MapAttributeBuilder
MapAttributeKey
If we ever need to support "any valued" attributes (i.e. heterogeneous arrays), then I think we could layer that on top of this using Option B.