lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Feedback on Match Query Parser (for fixing multiterm synonyms and other things)
Date Wed, 07 Sep 2016 23:57:29 GMT

: 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/

Mime
View raw message