Skip to content
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

[query] Fix bug with parsing Graphite find query #1676

Merged
merged 2 commits into from
May 30, 2019

Conversation

arnikola
Copy link
Collaborator

What this PR does / why we need it:

This fixes an issue with parsing graphite find queries. Previously, foo.* would get split up into foo, and *, which would go through a graphite globber and become [^\.]*, which would then not get correctly identified as a NewFieldQuery in the storage/index (this would convert regex values looking for .* only to a NewFieldQuery.

This PR adds MatchField and MatchNotField match types, and explicitly makes use of them in graphite queries, avoiding relying on implicit conversion in the storage layer.

Does this PR introduce a user-facing and/or backwards incompatible change?:

NONE
NONE

@codecov
Copy link

codecov bot commented May 29, 2019

Codecov Report

Merging #1676 into master will decrease coverage by <.1%.
The diff coverage is 64%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master   #1676     +/-   ##
========================================
- Coverage    71.8%   71.8%   -0.1%     
========================================
  Files         968     968             
  Lines       81169   81177      +8     
========================================
- Hits        58345   58339      -6     
- Misses      18990   19002     +12     
- Partials     3834    3836      +2
Flag Coverage Δ
#aggregator 82.4% <ø> (ø) ⬆️
#cluster 85.7% <ø> (ø) ⬆️
#collector 63.9% <ø> (ø) ⬆️
#dbnode 79.9% <ø> (-0.1%) ⬇️
#m3em 73.2% <ø> (ø) ⬆️
#m3ninx 74% <ø> (ø) ⬆️
#m3nsch 51.1% <ø> (ø) ⬆️
#metrics 17.6% <ø> (ø) ⬆️
#msg 74.7% <ø> (ø) ⬆️
#query 66.3% <64%> (-0.1%) ⬇️
#x 85.8% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c982091...6cadcca. Read the comment docs.

@robskillington
Copy link
Collaborator

Ah nice, I like the approach of using explicit match types too. Good stuff!

Copy link
Collaborator

@robskillington robskillington left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -38,6 +38,9 @@ enum MatcherType {
// matcher name rather than value
EXISTS = 4;
NOTEXISTS = 5;
// ALL superceeds other matcher types
// and does no filtering
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.'s

@@ -45,6 +45,20 @@ func TestConvertMetricPartToMatcher(t *testing.T) {
}
}

func TestConverWildcardToMatcher(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: spelling: Convert

@@ -45,6 +45,20 @@ func TestConvertMetricPartToMatcher(t *testing.T) {
}
}

func TestConverWildcardToMatcher(t *testing.T) {
metric := "*"
for i := 0; i < 100; i++ {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of a weird test -- why not just run this once?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to ensure that the metric name is also converted to expected (i.e. __g100__) as well

@@ -38,6 +38,10 @@ func (m MatchType) String() string {
return "=~"
case MatchNotRegexp:
return "!~"
case MatchField:
return "-"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding, how did you come up with these mappings?

Copy link
Collaborator Author

@arnikola arnikola May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made 'em up :p

It's not really a "standard" matcher type, and the only thing this affects is the String() method on MatchTypes so we should be fine here

@@ -192,6 +192,17 @@ func matcherToQuery(matcher models.Matcher) (idx.Query, error) {
}
return query, nil

case models.MatchNotField:
negate = true
fallthrough
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice - good use of fallthrough.

Copy link
Collaborator

@robskillington robskillington left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@benraskin92 benraskin92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@arnikola arnikola merged commit 744e0fd into master May 30, 2019
@arnikola arnikola deleted the arnikola/graphite-find branch May 30, 2019 15:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants