Remove `db.user`?

[trask]

It seems to overlap with #731.

I'm not sure that db.user is an important default database metric attribute, and so we could remove it for now, and capture database user on spans in the future under the user.* namespace once #731 is resolved.

[AlexanderWert]

Once #731 AND open-telemetry/build-tools#240 are resolved, we could re-introduce the user fields under the db namespace (if needed).

Similar to the conversation here #564 (comment), I think we should avoid ambiguous user.* attributes that are not in a concrete context (i.e. parent namespace). As user is a very generic concept we should put it into a parent namespace whenever it is being used in a concrete context, to make clear what kind of user it is. Otherwise, if a signal has user.* fields it's not clear what kind of user it refers to (the OS user running the underlying process? the Web user that is authenticated with the service? The DB user? etc.). And, in fact a single signal could even have multiple different users associated.

+1 on removing db.user attribute for now!

Later we can introduce the db.user.* namespace again with #731 and open-telemetry/build-tools#240

[jerry-shao]

Hi @trask @AlexanderWert

Seems the db.user is being used by users/venders currently: https://github.com/search?q=db.user+otel+span&type=code

May I know is it guaranteed that db.user will never be removed completely(only in deprecation mode) or there will be a replacement for sure (e.g. introduce user namespace under db namespace once the nested namespace is supported)?

[trask]

hi @jerry-shao! we definitely intend for there to be a replacement for capturing "database user", we're just not sure what the attribute name will be yet

[trask]

would you mind opening a new issue to track this, i.e. how to capture database user?

[jerry-shao]

Created a new issue to track this: #1142