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

Alessandro Benedetti commented on SOLR-16858:
---------------------------------------------

Sure [~hossman], let me explain here and if that old pull request is not 
relevant anymore, I'll proceed with a deep review of this PR (thanks for 
opening it, the fact you dislike the approach but you opened it nonetheless is 
much appreciated :)):

So the idea of the Pull Request I mentioned was to remove any filter query 
logic from the KNN Query parser and leave it to the standard way of managing 
filter queries, already available in Solr in QueryUtils 'public static Query 
combineQueryAndFilter'.
When I opened that tentative PR Lucene didn't allow me to instantiate a new Knn 
Query, copying the one already parsed and adding just the filter query, but now 
this would be possible (just updated the PR):
https://github.com/apache/solr/pull/1246/files

In this way, any filter should work as it works for any other Solr query (where 
you can decide if doing a prefilter of postfilter based on the cache and cost 
>100 of the filter).
Also, include/exclude should work as usual.

I checked the reranking issue and I don't think having a local FQ is 
necessary(or recommended) for that, but If you can think of other scenarios 
where a localFq would make sense, I am happy to listen.
Do we have other query parsers that have a local FQ?



> Allow KnnQParser to selectively apply filters
> ---------------------------------------------
>
>                 Key: SOLR-16858
>                 URL: https://issues.apache.org/jira/browse/SOLR-16858
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Joel Bernstein
>            Assignee: Chris M. Hostetter
>            Priority: Major
>              Labels: hybrid-search
>         Attachments: SOLR-16858-1.patch, SOLR-16858.patch
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The KnnQParser is parsing the filter query which limits the rows considered 
> by the vector query with the following method:
> {code:java}
> private Query getFilterQuery() throws SolrException, SyntaxError {
>     boolean isSubQuery = recurseCount != 0;
>     if (!isFilter() && !isSubQuery) {
>       String[] filterQueries = req.getParams().getParams(CommonParams.FQ);
>       if (filterQueries != null && filterQueries.length != 0) {
>         try {
>           List<Query> filters = QueryUtils.parseFilterQueries(req);
>           SolrIndexSearcher.ProcessedFilter processedFilter =
>               req.getSearcher().getProcessedFilter(filters);
>           return processedFilter.filter;
>         } catch (IOException e) {
>           throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>         }
>       }
>     }
>     return null;
>   }
> {code}
> This is pulling all filter queries from the main query parameters and using 
> them to limit the vector query. This is the automatic behavior of the 
> KnnQParser.
> There are cases where you may want to selectively apply different filters. 
> One such case is SOLR-16857 which involves reRanking a collapsed query.
> Overriding the default filter behavior could be done by adding an "fq" local 
> parameter to the KnnQParser which would override the default filtering 
> behavior.
> {code:java}
> {!knn f=vector topK=10 fq=$kfq}[...]&kfq=myquery
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to