[
https://issues.apache.org/jira/browse/SOLR-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450929#comment-13450929
]
Hoss Man commented on SOLR-1223:
--------------------------------
I had an idea about this a while back that i thought i posted as a comment but
apparently i forgot.
what if we implemented a very simple "or" (and for parity: "and") QParser that
took as it's input the _name_ of another (multivalued) param, which it then
iterated over, parsing each one according to the (possibly local) defType and
built up a BooleanQuery containing all of the resulting clauses. ie...
{noformat}
...
&fq={!or tag=model}models
&models=model:ford
&models=model:toyota
&models=model:gm
&fq={!or tag=color defType=field f=color}colors
&colors=Cherry Red
&colors=Green
...
{noformat}
As alluded to in this example, it would greatly simplify the input handling
needed when doing multi-select faceting
A possible later optimization would be for this OrQParser to actually return a
subclass of BooleanQuery implementing a special interface so that the
SOlrIndexSearcher would know if/when it could pull out the BooleanClauses to
cache them individually.
(The one concern i have about this idea is the unusualness of the input to this
parser being the *name* of another (multivalued) param -- people might be
confused with the more common convention of passing as input a dereferenced
param -- ie: '{{$param}}'))
> 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
>
> See this
> [issue|http://lucene.472066.n3.nabble.com/Query-Filter-fq-with-OR-operator-td499172.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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
