[
https://issues.apache.org/jira/browse/SOLR-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814552#comment-17814552
]
Chris M. Hostetter commented on SOLR-16858:
-------------------------------------------
{quote}I have some minor concerns over testing and documentation....
{quote}
I updated my branch to try to address your concerns, but as far some high level
responses/discussion...
* Re: changes to
{{knnQueryUsedInFilters_shouldFilterResultsBeforeTheQueryExecution}}
** Changing this test wasn't necessary because of the feature being added,
it's just a general improvement to the test i made to be confident i wasn't
breaking back compat
** On the main branch, this test doesn't really assert anything about the
{{knn}} parser – you could delete the knn filter from this test and it would
still pass
*** This is because "4" is already the only overlap between the {{q=id:(3 4 9
2)}} and {{fq=id:(4 20)}} params
** I added '9' to the {{fq=id:...}} to demonstrate that the knn filter was in
fact impacting the results
* Re: test splitting
** I went ahead and split up a bunch of the tests that you asked about
** I probably did not split as much as you wold like, but that's because I
tried to keep things together where:
*** The tests aren't just asserting the behavior of multiple inputs, they are
asserting exact equivalence in behavior for those inputs. Keeping them together
ensures that if at some point in the future a developer tries to change the
behavior – and thus change the test – they will be forced to consider the
equivalence assertions (and either update all the impacted code paths, or
intentionally break the equivalence)
*** Multiple assertions are _logically_ very related, even if the exact
input/output are distinct (ex:
{{knnQueryWithFilterQuery_preFilterLocalParamOverridesGlobalFilters}}
** In the specific case of {{QueryEqualityTest.testQueryKNN()}} that you asked
about: I don't view these as 4 diff test cases
*** There are 4 requests needed to have a diff parsing context (ie: diff
request params)
*** but the tests asserts that specific permutations of the resulting
{{Query}} objects are equal (or unequal) regardless of the parsing context
* Re: "may not" vs "must not"
** while "may" and "must" have very different meanings, "may not" and "must
not" are generally are interchangeable in english: with "may not" typically
considered friendlier & less abrasive.
** But if you found "may not" confusing as a non native speaker, then
presumably other non native speakers (with less understanding of the underlying
subject matter) will be equally confused
** So i switched them all to "must not" for clarity
> 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: 0.5h
> 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
