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