Split `db.query.parameter.<key>` to include the parameter type

[wertzui]

Area(s)

area:db

Is your change request related to a problem? Please describe.

When sending a command to a database, the parameters may have a type associated with them (in MSSQL they always have, not sure about other databases).
At the moment only the value of the parameter is stored, but not the type.

Describe the solution you'd like

Split db.query.parameter.<key> into

• db.query.parameter.<key>.value which stores the value as previously db.query.parameter.<key>
• db.query.parameter.<key>.type which stores the parameter type

Describe alternatives you've considered

One possibility would be to store the type as part of the value, like

db.query.parameter.foo=42 (Int32)

However parsing this now need special logic, especially for strings.

Additional context

Related to #866

[trask]

Discussed in db semconv meeting, and suggestion is to keep db.query.parameter.<key> and introduce db.query.parameter.type.<key>

[trask]

there could be overlap if there is a <key> named type

not as nice, but a workaround could be db.query.parameter_type.<key>

[lmolkova]

Would it make sense to keep db.query.parameter.<key> experimental for now? What it buys us is if/when complex attributes on spans are supported, we can declare db.query.parameter.<key> to have any value. In practice, it just means a union of primitive types.

The type information would be part of the OTLP payload and there is no need for a separate attribute.

[trask]

we can declare db.query.parameter.<key> to have any value

I think this also gives us a solution to capturing null values (I think any attributes support null value while string attributes do not)

related:

• Added JDBC db.query.parameter span attributes opentelemetry-java-instrumentation#13719 (comment)
• Officially treat @Nullable value in AttributesBuilder.put() as a no-op opentelemetry-java#4336