lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-6318) QParser for TermsFilter
Date Mon, 08 Sep 2014 03:06:29 GMT


David Smiley commented on SOLR-6318:

Cool []; thanks for spending the time benchmarking it.  Could you try some
of the other methods supported besides termsFilter:  method=automaton and method=docValuesTermsFilter

> QParser for TermsFilter
> -----------------------
>                 Key: SOLR-6318
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: query parsers
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 4.10
>         Attachments: SOLR-6318__terms_QParser.patch
> Some applications require filtering documents by a large number of terms.  It's often
related to security filtering.  Naively this is done this way:
> {noformat}
>     fq={!df=myfield q.op=OR}code1 code2 code3 code4 code5...
> {noformat}
> And this ends up being a BooleanQuery.  Users then wind up hitting BooleaQuery.maxClauseCount
(sometimes in production, sadly) and they up it to a huge number to get the job done.
> Solr should offer a QParser based on TermsFilter.  I propose it be named "terms" (plural
of term), and have a "separator" option defaulting to a space.  When it's a space, the values
also get trimmed, which wouldn't otherwise happen.  The analysis logic should be the same
as that for "term" QParser which is to call FieldType.readableToIndexed.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message