lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Gibney (JIRA)" <>
Subject [jira] [Commented] (SOLR-7798) Improve robustness of ExpandComponent
Date Thu, 22 Feb 2018 15:41:00 GMT


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]

> Improve robustness of ExpandComponent
> -------------------------------------
>                 Key: SOLR-7798
>                 URL:
>             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:
For additional commands, e-mail:

View raw message