: I wanted to solicit feedback on my query parser, the match query parser (
: https://github.com/o19s/match-query-parser). It's a work in progress, so
: any thoughts from the community would be welcome.
:
: The point of this query parser is that it's not a query parser!
2 Thoughts based purely on reading your email and the README.md, in no
particular order...
1) in "phrase" mode, what does this do if/when the analyzer produces
multiple terms at teh same position? ... ie: i understand how it can
address the "({[sea]@0 [biscut]@1}) => ({[seabiscut]@0})" multiword =>
single word synonym case at query time, and i get that in "term" mode, it
can build a disjunctionmaxquery out of any forks in the tokenstream, but
how does the "phrase" option behave with the multiword to multiword(s) of
possibly diff length type situation, ie: ({[sea]@0 [biscut]@1}) =>
({[seabiscut]@0}, {[see]@0 [biscut]@1}, {[see]@0 [biz]@1 [cut]@2}) ?
2) I can't see any downsides to adding these options as optional features to
the
existing {!field} parser ?
- qf - not needed since we already have the existing f param
- analyze_as - default to the type of the field specified by f
- search_with - default to phrase for back compat
- mm - prob best to default to 0 or top level mm?
- pslop - prob best to default to 0 or top level ps?
(perhaps rename as 'ps' to be consistent?)
-Hoss
http://www.lucidworks.com/
