Skip to content

search: add basic parameter scanning to query parser

Administratorrequested to merge
rvt/query-parser-scanner into master

Created by: rvantonder

This PR changes the previous

type Parameter {
	Value string
}

to

type Parameter struct {
	Field   string
	Value   string
	Negated bool
}

I thought deeply about where to draw the line of parsing a "parameter" at this low level parsing stage. Please see comment for ScanParameter for what it entails. I chose this way because I'd like our literal parser (or any parser, ever, really) to have a low level representation of a 'parameter' that can then decide what it considers to be valid or not. The logic is, in essence, a minimal unvalidated interpretation that doesn't lose or throw away (e.g. by, unquoting, etc.) any syntactic information that could potentially be useful in a search, and cannot fail. For example, if literal search wanted to search for ", it should be able to get that value in a leaf node by using ScanParameter. And, indeed, the current approach allows this.

I fully plan to migrate our literal search parser to use ScanParameter. Note that ParseParameter is the caller that is specific to AND/OR query parsing (it is less general than ScanParameter) which is why these two functions are kept separate.

A note on NOT: don't think about it in the context of this PR right now. When introduced, it will serve as syntactic sugar, specific to AND/OR queries, that influences the Negated field of a parameter. In the future, NOT may apply to whole expressions, which will then be promoted to it's own Operator, rather than syntactic sugar on Parameters

Merge request reports