Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <2017795416.1246065107172.JavaMail.jira@brutus>
Date: Fri, 26 Jun 2009 18:11:47 -0700 (PDT)
From: "Lance Norskog (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-1223) Query Filter fq with OR operator
In-Reply-To: <1816063845.1245177307380.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724781#action_12724781 ] 

Lance Norskog commented on SOLR-1223:
-------------------------------------

The problem with BP's suggestion is that (fq1 & fq2) OR (fq3 & fq4) is not possible. One ends up wanting to do everything with NAND. Or postfix notation.

To have a tree-structured AND/OR/NOT expression we need to name the individual filter queries and then reference them in a tree.

    fq1=query
    fq2=query
    fq3=query
    fq4=query

    fq=(fq1 AND fq2) OR (fq3 & fq4)

This can be done without naming filters if we just have something that finds filter queries as subtrees in a given query. If "field:3" is a cached filter query, this tree-walker would find that cached filter in fq="+a +field:3". It would then do a search of "+a" applying the existing filter "field:3". 

I vote for named filters as the most transparent system for dynamically compositing filters.


> Query Filter fq with OR operator
> --------------------------------
>
>                 Key: SOLR-1223
>                 URL: https://issues.apache.org/jira/browse/SOLR-1223
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>            Reporter: Brian Pearson
>            Priority: Minor
>
> See this [issue|http://www.nabble.com/Query-Filter-fq-with-OR-operator-td23895837.html] for some background.    Today, all of the Query filters specified with the fq parameter are AND'd together.  
> This issue is about allowing a set of filters to be OR'd together (in addition to having another set of filters that are AND'd).    The OR'd filters would of course be applied before any scoring is done.  
> The advantage of this feature is that you will be able to break up complex filters into simple, more cacheable filters, which should improve performance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.