Looks interesting. I especially like "we analyze it" and then "we analyze/space-split it again" as the last tutorial example.
Regards, Alex. P.s. Cool enough for http://solr.cool/ ? ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 2 September 2016 at 07:45, Doug Turnbull <dturnb...@opensourceconnections.com> wrote: > 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! > > Instead, it's a way of selecting any analyzer to apply to the query string. I > use it for all kinds of things, finely controlling a bigram phrase search, > searching with stemmed vs exact variants of the query. > > But it's biggest value to me is as a fix for multiterm synonyms. Because > I'm not giving the user's query to any underlying query parser -- I'm > always just doing analysis. So I know my selected analyzer will not be > disrupted by whitespace-based query parsing prior to query analysis. > > Those of you also in the Elasticsearch community may be familiar with the > match query ( > https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html > ). This is similar, except it also lets you select whether to turn the > resulting tokens into a term query body:(sea\ biscuit likes to fish) or a > phrase query body:"sea biscuit" likes to fish. See the examples above for > more. > > It's also similar to Solr's field query parser. However the field query > parser tries to turn the fully analyzed token stream into a phrase query. > Moreover, the field query parser can only select the field's own query-time > analyzer, while the match query parser let's you select an arbitrary > analyzer. So match has more bells and whistles and acts as a compliment to > the field qp. > > Thanks for any thoughts, feedback, or critiques > > Best, > -Doug
