lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Pearson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1223) Query Filter fq with OR operator
Date Wed, 17 Jun 2009 15:26:07 GMT

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

Brian Pearson commented on SOLR-1223:
-------------------------------------

Just putting my thoughts out .. obviously don't have the same understanding as Yonik :)

Feels like specifying which filter's are cached doesn't need to be part of this issue.  This
issue could just be about specifying the boolean logic that gets applied to the Doc Maps that
are created by the filters.  So today you have a number of filters .. F1, F2, ... FN and the
boolean logic is F1 & F2 & .. &FN

What I'm hoping for is something simple where you have 2 groups, the AND group and the OR
group.   
AND group: A1, A2
OR group: O1, O2

So the filter you end up with is (A1 & A2) & (O1 | O2).  The caching logic doesn't
need to change then, there are still 4 filter queries.  

Real example:

Current method
fq=popularity:[10 TO *] OR section:0 
fq=type:2

New method (assuming we added ofq for the OR'd filter query group, probably there is a better
way to make the API )
ofq=popularity:[10 TO *] 
ofq=section:0
fq=type:2

I realize I'm probably missing some important implementation details that Yonik alludes to,
just wanted to get my thoughts down.  I wish I was in a position to actually work on this
.. if someone takes this on, I can help with beta testing and documentation.

If anyone cares, the reason I want this is because my apps have extremely complicated authorization
logic.   I can do what I need using fq's, but the filters get large and are very specific
to the user that did the search.  If I had OR logic, then I could break the filters down into
smaller pieces, which would be much more reusable from the cache, and performance would be
much better

Thanks for listening :)

> 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.


Mime
View raw message