-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement deletion based on partially matching labels #1013
Conversation
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
0eba7e4
to
9a8cb32
Compare
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.
Nice! It looks quite good to me however, I personally did not have a code that needs functionality like this. This is why it would be amazing to have opinions from potential users: @taiyang-li @pstibrany
I added a small comment though, I think the DeletePartialMatchLabelValues(values..)
semantics is too open. I wonder if DeletePartialMatchLabelValues(name, values ...)
make more sense (:
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
0aae467
to
e79ef55
Compare
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
This is the exact function I needed . |
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Signed-off-by: Zach Stone <[email protected]>
Ok, I've updated this PR with what I think @beorn7 had in mind. I am open to returning an error if a user passes a curried label to |
I'm aware, and this is on my review queue, but the queue is very long and progressing slowly. I'll get to this eventually, but feel free to make the call without me. |
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.
Thanks 💪🏽
Great!
I think it's safe to merge as the API got smaller and very sensible, but waiting for your eyes @beorn7 if you want to check it still. I am happy with this (: |
Signed-off-by: Zach Stone <[email protected]>
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.
Semantics looks OK to me now.
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.
LGTM
func (m *MetricVec) DeletePartialMatch(labels Labels) int { | ||
return m.metricMap.deleteByLabels(labels, m.curry) | ||
} |
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.
What is the computational complexity of this function? I imagine it is O(metrics count)
, right?
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.
Correct. I hoped to find a constant time implementation but didn't find one (at least at the time)
Towards #834. This is an approach which I think feels user-friendly and accomplishes what folks were asking for. Open to suggestions of course, I'm new here.
This PR introduces a new deletion method:
DeletePartialMatch(labels Labels)
- deletes a metric if all of the given labels and associated values are present in that metric.It returns the number of metrics which were deleted.