[ 
https://issues.apache.org/jira/browse/SOLR-9494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-9494:
-------------------------------
    Attachment: 
SOLR_9494__CollapseQParser_s_collectors_should_override_needsScores__.patch

Attached is the patch with a test.

In addition to the SpanQuery, the test needed to incorporate facets (to thus 
need a DocSet), have caches, and to execute the query twice to execute a 
different code path the 2nd go around for a successful cache retrieval.

I also removed the boolean field cscore which is redundant with boolean 
needsScore.  if cscore is true, needsScore certainly is too since the existence 
of cscore is one of the reasons needsScore can be set to true.

I plan to commit this once tests pass; it takes awhile.

> CollapseQParserPlugin doesn't propagate needsScores() correctly
> ---------------------------------------------------------------
>
>                 Key: SOLR-9494
>                 URL: https://issues.apache.org/jira/browse/SOLR-9494
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: David Smiley
>            Assignee: David Smiley
>         Attachments: 
> SOLR_9494__CollapseQParser_s_collectors_should_override_needsScores__.patch
>
>
> CollapseQParserPlugin internally has a number of Lucene Collector 
> implementations, all of which extend Solr DelegatingCollector which provides 
> a default implementation of the method needsScores() based on what it's 
> delegating too.  But Collapsing's collectors fail to consider that these 
> collectors _themselves_ sometimes need the score, irrespective of wether or 
> not a delegate might.
> In most cases nobody would notice this bug because most queries don't seem to 
> care.  However, SpanQueries are cranky about this, which will either throw an 
> AssertionError or NPE if you ask for a score without saying in advance you 
> wanted them.
> I have a patch forthcoming, but am having trouble ATM reproducing to create a 
> test.  The most straight-forward test doesn't trip it.  I have a failing test 
> in a client environment, and a patch that fixes it.  Reproducing seems to 
> involve a cached query somehow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to