I just want to surface this again in case it got missed; it's a small gap,
but it seems buggy that we can support setMissingValue for SortFields based
on concrete numeric fields, but not for abstract values sources that are
numeric and have the same "missing value" semantics - ie when the source
does not advance to a doc, it has no value for that doc.
I think the gap can be addressed by adding fairly trivial overrides for
LongValuesSource.LongValuesSortField.setMissingValue and
DoubleValuesSource.DoubleValuesSortField.setMissingValue, adding the
missing value to the corresponding ComparatorSource classes, and ensuring
it doesn't get dropped in SortField.rewrite(). I'm happy to provide a patch
if it would be welcome.
On Wed, Mar 27, 2019 at 12:26 PM Michael Sokolov <msoko...@gmail.com> wrote:
> The ValuesSources provide a getSortField method that always supplies 0 as
> the "missing value" - ie the default value for documents that do not
> advance the source.
>
> But if an application wants to provide "missing last" or "missing first"
> semantics, it needs to control the missing value depending on the possible
> range of values and whether the sort is ascending or descending.
>
> Yet if you call setMissingValue() on one of these SortFields, you get an
> Exception:
> throw new IllegalArgumentException("Missing value only
> works for numeric or STRING types");
>
> But these *are* numeric types, or they seem that way. Internally they are
> labeled as type CUSTOM.
>
> First, my question is whether there is a way to achieve the desired
> behavior -- missing last semantics combined with sorting on ValuesSource?
>
> And if there isn't a good way, would it make sense to default to "missing
> last", providing a default value of MIN or MAX depending on whether the
> sort is descending or ascending, or maybe just allow setMissingValue to be
> called for these fields?
>
