lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-6318) QParser for TermsFilter
Date Thu, 07 Aug 2014 18:06:12 GMT


ASF subversion and git services commented on SOLR-6318:

Commit 1616559 from [~dsmiley] in branch 'dev/branches/branch_4x'
[ ]

SOLR-6318: New terms QParser

> 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