Make Resource.Merge consistent with Span.SetAttribute. #1345
Conversation
Oberon00
added
area:sdk
Oberon00
force-pushed
the
resource-merge-reverse
branch
from
950f8c2
to
39fafa5
Compare
|
LGTM |
|
Actually, with the new behavior, I would like to change the specified name from |
|
Preference for Merge over UpdatedWith since it's shorter. For some reference, JS has the reasonably short |
| @@ -43,27 +43,21 @@ Required parameters: | |||
|
|
|||
| ### Merge | |||
|
|
|||
| The interface MUST provide a way for a primary resource and a | |||
| secondary resource to be merged into a new resource. | |||
| The interface MUST provide a way for an old resource and an | |||
There was a problem hiding this comment.
| The interface MUST provide a way for an old resource and an | |
| The interface MUST provide a way for an existing resource and an |
There was a problem hiding this comment.
The other resource also exists. Maybe "updated", and rename "updating" to "new"? Or "previous" and "new".
There was a problem hiding this comment.
"old" makes it sound like it's.... old, which is might not be at all.
There was a problem hiding this comment.
I named it "old" to emphasize that the values in there may be overwritten by the other resource. But I agree that the name is a bit odd. Maybe we could specify it as a member function resource.Merge(updating). Then we don't have to come up with a name for the left-hand-side.
EDIT: If I get some more upvotes from approvers on this comment, I'll change the PR (assuming this is an editorial-only change)
|
|
||
| Attribute key namespacing SHOULD be used to prevent collisions across different | ||
| resource detection steps. | ||
| If a key exists on both the old and updating resource, the value of the updating |
There was a problem hiding this comment.
| If a key exists on both the old and updating resource, the value of the updating | |
| If a key exists on both the existing and updating resource, the value of the updating |
| Attribute key namespacing SHOULD be used to prevent collisions across different | ||
| resource detection steps. | ||
| If a key exists on both the old and updating resource, the value of the updating | ||
| resource MUST be picked (even if the updated value is empty). |
There was a problem hiding this comment.
About the behavior for empty strings? I hope so, it is one special case we lose.
There was a problem hiding this comment.
Ping @bogdandrutu ;)
|
@Oberon00 Please rebase your branch ;) |
|
@carlosalberto Done. |
This reflects a change in the specification itself. open-telemetry/opentelemetry-specification#1345
* Reverse order of attribute precedence when merging two Resources This reflects a change in the specification itself. open-telemetry/opentelemetry-specification#1345 * Resolves #1500 Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
…n-telemetry#1501) * Reverse order of attribute precedence when merging two Resources This reflects a change in the specification itself. open-telemetry/opentelemetry-specification#1345 * Resolves open-telemetry#1500 Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Reverse order of attribute precedence when merging two Resources This reflects a change in the specification itself. open-telemetry/opentelemetry-specification#1345 * Resolves #1500 Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Required for #1346.
Resolves parts of #1184.
As agreed (except for the empty-string change) in the spec meeting, this is a pre-requesite for the updated default resource wording of #1294.
Changes