Thanks Alan, that might be doable. What would the outer query look like? A big dismax across the fields with a tie parameter? (ala Elasticsearch most/best fields)?
If you did that, you'd probably also want to control the query parser's behavior per field. For example, one field you want to analyze with synonyms and search with phrases. Another perhaps you're doing a bigram search, etc. Perhaps something like facets field-specific local params would be needed? -Doug On Fri, Sep 2, 2016 at 3:57 AM Alan Woodward <a...@flax.co.uk> wrote: > This looks very useful! It would be nice if you could also query multiple > fields at the same time, to give more edismax-like functionality. In fact, > you could probably extend this slightly to almost entirely replace edismax, > by allowing multiple fields and multiple analysis paths. > > Alan Woodward > www.flax.co.uk > > > > On 2 Sep 2016, at 01: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 > >
