Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dynamodb attributes are in aws namespace instead db #186

Open
Flarna opened this issue Jul 10, 2023 · 6 comments
Open

dynamodb attributes are in aws namespace instead db #186

Flarna opened this issue Jul 10, 2023 · 6 comments
Assignees

Comments

@Flarna
Copy link
Member

Flarna commented Jul 10, 2023

The span attributes for dynamodb are currently in aws namespace.

Other databases like mondodb or mssql have their special attributes in the db namespace.

At other places like cloud.region vendor namespaces are also replaced/avoided by a generic namespace.

Should the dynamodb attributes moved to db namespace?

@Oberon00
Copy link
Member

Oberon00 commented Jul 11, 2023

I think it's kind of a wash. All aws-API-specific attributes start with aws., all db-related ones with db.. You can't have both. There are some remarks regarding use of db.* e.g. at open-telemetry/opentelemetry-specification#1422 (comment)

@github-actions github-actions bot added the Stale label Feb 16, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 26, 2024
@joaopgrassi joaopgrassi removed the Stale label Feb 26, 2024
@joaopgrassi
Copy link
Member

This was closed by mistake by the stale bot. Re-opening

@joaopgrassi joaopgrassi reopened this Feb 26, 2024
@joaopgrassi
Copy link
Member

fyi @trask

@trask
Copy link
Member

trask commented Apr 24, 2024

I'd vote for the db.* prefix to be given precedence since that seems like the more important grouping from semantic convention perspective.

@trask
Copy link
Member

trask commented Apr 26, 2024

even if we aren't targeting dynamodb as part of initial database semconv stability, I think we should make this change as part of the initial database semconv stability process so that this breaking change could benefit from being grouped with the other breaking changes related to stabilization

@trask trask assigned trask and unassigned jsuereth May 8, 2024
@trask
Copy link
Member

trask commented May 8, 2024

I thought about this some more and changed my opinion.

we should try to stick with the philosophy "try to consolidate all breaking changes into a single bump when going stable"

and so we should defer this change until we are planing dynamodb semconv stabilization (which is not included as part of initial db semconv stability)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Post Stability
Development

No branches or pull requests

5 participants