[
https://issues.apache.org/jira/browse/SOLR-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728201#comment-14728201
]
Hoss Man commented on SOLR-8005:
--------------------------------
FWIW: i initially thought the best "fix" would be for the various impls of
"getSingleValueSource" in Solr field types to override
SortedSetFieldSource.getSortField to call {{setMissingValue(0)}} as part of the
constructor -- but SortedSetSortField only supports STRING_FIRST and
STRING_LAST as valid options for setMissingValue ... which in hind sight made
perfect sence, since SortedSetSortField uses a TermOrdValComparator under the
covers and never actually inspects/decodes any bytes.
> when some docs have no values, sorting on field(multivalued_field,min/max)
> has inconsistent ordering compared to sorting on same effective values in a
> single valued field
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8005
> URL: https://issues.apache.org/jira/browse/SOLR-8005
> Project: Solr
> Issue Type: Bug
> Affects Versions: 5.4
> Reporter: Hoss Man
>
> While working on tests for SOLR-8001 i realized that because the multivalued
> min/max selector function (ie: {{field(multivalued_field_name,min)}} produces
> a ValueSource which is a {{SortedSetFieldSource}} instance, and because
> SortedSetFieldSource uses SortedSetSortField when sorting, then in situations
> where some documents do not have any value at all in the multivalued field
> the sort order will be inconsistent compared to sorting on a single valued
> numeric field containing the same "effective" min/max value (where docs w/o a
> value act as if the value is "0" by default).
> ie: {{sort=min_of_multivalued_field_name+asc}} vs
> {{sort=field(multivalued_field_name,min)+asc}} will not sort identically.
> ----
> I don't have any immediate ideas for a "fix" to make these situations more
> equivilent, but the current known workarround for people that want equivilent
> behavior is to wrap the {{field}} function in a {{def}} function selecting a
> default value of {{0}} -- ie:
> {{sort=def(field(multivalued_field_name,min))+asc}}.
> If the function is already wrapped in some other numeric function, then the
> behavior (combined with the existing bug fix in SOLR-8001) should already be
> equivilent -- ie: {{sort=sum(32,min_of_multivalued_field_name)+asc}} vs
> {{sort=sum(32,field(multivalued_field_name,min))+asc}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
