[
https://issues.apache.org/jira/browse/SOLR-18020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-18020:
--------------------------------------
Attachment: SOLR-18020.test.patch
Status: Open (was: Open)
Attaching a {{QueryEqualityTest}} patch that demonstrates failures when queries
that should be equals (and have equal hashCode) exclusively use negative fq
params.
I haven't fully wrapped my head around *why* this happens – but i suspect it
has to do with some of the hairy code in
{{SolrIndexSearcher.getProcessedFilter()}} and if/how the method behaves
differently when all of the filters are negative .. but i got a headache trying
to follow the logic in that method.
> KnnFloatVectorQuery cache misses when prefiltering (fq) params are negative
> ---------------------------------------------------------------------------
>
> Key: SOLR-18020
> URL: https://issues.apache.org/jira/browse/SOLR-18020
> Project: Solr
> Issue Type: New Feature
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-18020.test.patch
>
>
> From the mailing list....
> [https://lists.apache.org/thread/3zl69n9vyjlhrlx7h3133cnb644rgno6]
> {quote}I have encountered an issue that the KnnFloatVectorQuery could not get
> the superset from queryResultCache when I have negative filters in the
> request.
> For example, {{{}fq=-some_field:value{}}}. But with positive fq it works fine:
> {{fq=some_field:value}}
> {quote}
> The working theory is that these cache failures (and inconsistent behavior
> between positive vs negative {{fq}} params) relates to the lack of hashCode
> (and equals) implementations in {{DocSet}} impls – even though
> {{DocSetQuery}} explicitly calls {{DocSet.hashCode}} (and {{DocSet.equals}}
> in it's own impls
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
