-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: use an equivalent fixed column for tag attributes #5028
base: develop
Are you sure you want to change the base?
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. |
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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.