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.
No description provided.