Michael Gibney commented on SOLR-7798:

Thanks, [~joel.bernstein]. I'm happy to prep a PR, but would you mind first 
confirming that {{count}} (and its associated ceiling of 200) is intended to 
represent the number of matching collapse _values_, as opposed to the number of 
result documents associated with those values? Assuming that's the case, is 
there any reason to continue trac{{king }}{{count}} externally (as opposed to 
simply relying on {{ordBytes.size(), as in [~joergr]'s 
[^expand-component.patch] patch}})?

> Improve robustness of ExpandComponent
> -------------------------------------
>                 Key: SOLR-7798
>                 URL: https://issues.apache.org/jira/browse/SOLR-7798
>             Project: Solr
>          Issue Type: Improvement
>          Components: SearchComponents - other
>            Reporter: Jörg Rathlev
>            Assignee: Joel Bernstein
>            Priority: Minor
>         Attachments: expand-component.patch, expand-npe.patch
> The {{ExpandComponent}} causes a {{NullPointerException}} if accidentally 
> used without prior collapsing of results.
> If there are multiple documents in the result which have the same term value 
> in the expand field, the size of the {{ordBytes}}/{{groupSet}} differs from 
> the {{count}} value, and the {{getGroupQuery}} method creates an incompletely 
> filled {{bytesRef}} array, which later causes a {{NullPointerException}} when 
> trying to sort the terms.
> The attached patch extends the test to demonstrate the error, and modifies 
> the {{getGroupQuery}} methods to create the array based on the size of the 
> input maps.

This message was sent by Atlassian JIRA

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

Reply via email to