chore: use an equivalent fixed column for tag attributes #5028
Conversation
|
Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id> |
|
How about updating the logic to only show the original attributes and updating the query builder logic to use the column in the query for those attributes which have a column. This leads to an experience that doesn't require any explanation for what is different b/w dbSystem and |
But we want to show users which column is indexed and which is not. |
|
You can still show that they are indexed like logs do with the same original attribute names. |
makeavish
changed the title
|
Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id> |
1 similar comment
|
Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id> |
| spanKeys["http.request.header.host"] = v3.AttributeKey{ | ||
| Key: "httpHost", | ||
| Type: v3.AttributeKeyTypeTag, | ||
| IsColumn: true, | ||
| DataType: v3.AttributeKeyDataTypeString, | ||
| } | ||
| spanKeys["server.address"] = v3.AttributeKey{ | ||
| Key: "httpHost", | ||
| Type: v3.AttributeKeyTypeTag, | ||
| IsColumn: true, | ||
| DataType: v3.AttributeKeyDataTypeString, | ||
| } | ||
| spanKeys["client.address"] = v3.AttributeKey{ | ||
| Key: "httpHost", | ||
| Type: v3.AttributeKeyTypeTag, | ||
| IsColumn: true, | ||
| DataType: v3.AttributeKeyDataTypeString, | ||
| } |
There was a problem hiding this comment.
Since the equivalent change in collect is recent and not released yet, we either have to hold this PR for enough data to backfill or just comment out these new additions so users don't see incorrect results for longer time ranges.
| @@ -85,18 +85,17 @@ func getClickhouseTracesColumnDataTypeAndType(key v3.AttributeKey) (v3.Attribute | |||
| } | |||
|
|
|||
| func enrichKeyWithMetadata(key v3.AttributeKey, keys map[string]v3.AttributeKey) v3.AttributeKey { | |||
| if key.Type == "" || key.DataType == "" { | |||
There was a problem hiding this comment.
I guess what breaks with removing this is when there is an attribute different type or datatype, irrespective of what user explicitly selects their preferred type and datatype, we override? I am not sure how much of a real problem this is. I have come across any customer who had the same attribute name with a different type or data type.
There was a problem hiding this comment.
That might be an issue but only when user is using custom attribute key with same name as otel key. I haven't encountered any users with the same attribute name and different types.
In logs too we are also overriding them.
There was a problem hiding this comment.
That might be an issue but only when user is using custom attribute key with same name as otel key. I haven't encountered any users with the same attribute name and different types. In logs too we are also overriding them.
There are a few users with the same key but different type/data type and they are not necessarily because of the custom attribute collision with otel key. See #5150 & #5359; @nityanandagohain created the issue after a bug request from a customer and then oss user also added that they are impacted by it.
There was a problem hiding this comment.
That might be an issue but only when user is using custom attribute key with same name as otel key. I haven't encountered any users with the same attribute name and different types. In logs too we are also overriding them.
There are a few users with the same key but different type/data type and they are not necessarily because of the custom attribute collision with otel key. See #5150 & #5359; @nityanandagohain created the issue after a bug request from a customer and then oss user also added that they are impacted by it.
Yeah, I saw community user faced the issue.
Let's block this until we find a fix
There was a problem hiding this comment.
They are independent problems, aren't they? Could we modify this pull request to still honor the user's selection (assuming the request payload is accurate), but for the attributes we know have fixed columns, use those instead?
No description provided.