[Prototype] attribute: add complex value types #6809
Conversation
|
@open-telemetry/go-maintainers, do you think that there anything more that I should add/check in order to validate the open-telemetry/opentelemetry-specification#4485? |
pellared
changed the title
pellared
requested review from
MrAlias,
XSAM,
dashpole and
dmathieu
as code owners
pellared
changed the title
|
SIG meeting: |
pellared
changed the title
| } | ||
|
|
||
| // MapValue creates a MAP Value. | ||
| // v is sorted by key. |
There was a problem hiding this comment.
We should also deduplicate keys, but this is an implementation detail not relevant for the prototype.
| // | ||
| // If creating both a key and value at the same time, use the provided | ||
| // convenience function instead -- Slice(name, value). | ||
| func (k Key) Slice(v []Value) KeyValue { |
There was a problem hiding this comment.
This should be better called Array to match the OTel Spec.
There was a problem hiding this comment.
😁 For reference only, a recommendation from AI: Sequence.
I consulted AI to obtain an answer based on a neutral stance across multiple languages.
https://chatgpt.com/share/68beda19-2a1c-800c-8eb6-0e31bf7a8170 —— The content is in Chinese; please translate it into English yourself for reference.
2 participants
Prototype for open-telemetry/opentelemetry-specification#4485
This PR is to validate that it is possible to extend attributes with complex attributes without making breaking changes and making sure that
Valueis still comparable.It does not implement everything. I was just focused how we are able to handle the following new attribute value types in a backwards compatible way:
This PR does not update the code dependent on attributes package. Exporters do not export complex attributes and the Logs API do not use this package. Nothing prevents doing it and I think this is not necessary to validate the OTEP.