You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The function is complex and error-prone, especially when all symbols are supported in metric names
The solution
The proposed solution is to have a separate private field in the MetricData struct to store the metric name clean from function names, so it's taken from there whenever it is needed.
The text was updated successfully, but these errors were encountered:
This idea came out of the following discussion: #686 (comment)
The problem
Some functions need the name of the metric clean from function names (usually to split it into nodes). For example:
carbonapi/expr/helper/helper.go
Lines 95 to 96 in b1e09e9
The problem is that the
"name"
is not always clean from functions. For example: https://github.com/graphite-project/graphite-web/blob/ed08fa4e2f6526ae11e55f88f70d0b6d36e4052f/webapp/graphite/render/functions.py#L243-L249 . In that case,strings.Split("sumSeries(foo.bar)", ".")
returns"sumSeries(foo"
,"bar)"
, which is not the wantednodes
.The first (currently implemented) solution for this is to call
ExtractNameTag
when the clean metric name is needed: https://github.com/grafana/carbonapi/blob/7b2a1ee8bfcba3bb1aba9619dc2f39d3cf9622c0/expr/helper/helper.go#L95-L96 (at time of writing, this is close to being merged here). But we want to avoid calling this function because:The solution
The proposed solution is to have a separate private field in the MetricData struct to store the metric name clean from function names, so it's taken from there whenever it is needed.
The text was updated successfully, but these errors were encountered: