previously, the only way to get numeric matching was with the
range operators :> :>= :< :<=
now, when we encounter field:val if the val can be parsed as a
number, then we do a disjunction search, which includes
searching for val as a text term and as an exact numeric value
1) disjunction and conjunction queries now support a
"query string mode". By default they do not operate
in this mode. When in this mode, any disjunct/conjunct
which evaluates to MatchNone searcher, will be removed
from the disjunction/conjunction. If the query ends
up with NO conjuncts/disjuncts, it will itself
return the MatchNone seacher.
2) boolean query also supports a query string mode. when in
this mode, the Must, Should and MustNot searchers are all put
into query string mode.
3) rewriting of negation only queries (like -foo) now take into
account the rewriting rules above, and those are handled first.
this means that we rewrite correctly in case of +stoword -foo
4) the empty query string is now valid, and returns 0 hits.
previously this was considered a validation error.
some downstream applications need to know which sub-commands
may alter the index. this new function allows them to be
identified, while not prescribing any particular behavior.
we now use a multiphrase query in all cases
internally its optimized to be the same as regular phrase query
anyway, and we simplly map all the tokens in the stream into
a multi-phrase query with the appropriate structure
when parsing json, when we encounter the key "terms", we first
try to parse as traditional phrase query, then if that fails,
we also try parsing it as multi-phrase
the logic of how a phrase search works should be an internal
detail of the phrase searcher. further, these changes will
allow proper scoring of phrase matches, which require access
to the underlying searcher objects, which were hidden in the
previous approach.
this originated from a misunderstanding of mine going back
several years. the values need not be float64 just because
we plan to serialize them as json.
there are still larger questions about what the right type should
be, and where should any conversions go. but, this commit
simply attempts to address the most egregious problems
at the core, the Next() method moves another searcher forward
and checks each hit to see if it also satisfies the phrase
constraints. the current implementation has 4 nested for loops.
these nested loops make it harder read (indentation) and harder
to reason about (complexity).
this refactor does not remove any loops, it simply moves some
of the inner loops into separate methods so that one can
more easily reason about the parts separately.
