[
https://issues.apache.org/jira/browse/LUCENE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15647858#comment-15647858
]
Ferenczi Jim commented on LUCENE-7537:
--------------------------------------
> The new types do not look useful to me?
It's to differentiate the underlying DVs and also because I didn't want to
change the expectation of the native sort. Though I am totally for a single
type that accepts both DVs if changing the SortField native types is ok.
> For instance, DocValues.getSortedSet falls back to
> LeafReader.getSortedDocValues if the reader does not have SORTED_SET doc
> values, so all the code that you protected under eg. if (sortField.getType()
> == SortField.Type.SORTED_STRING) would also work with single-valued (SORTED)
> doc values (same for SORTED_NUMERIC and NUMERIC doc values).
The leniency is here to catch SortedSetDocValues that ends up with a single
value per field. But yes it's another point for the merged type.
> Add multi valued field support to index sorting
> -----------------------------------------------
>
> Key: LUCENE-7537
> URL: https://issues.apache.org/jira/browse/LUCENE-7537
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
> Reporter: Ferenczi Jim
> Attachments: LUCENE-7537.patch
>
>
> Today index sorting can be done on single valued field through the
> NumericDocValues (for numerics) and SortedDocValues (for strings).
> I'd like to add the ability to sort on multi valued fields. Since index
> sorting does not accept custom comparator we could just take the minimum
> value of each document for an ascending sort and the maximum value for a
> descending sort.
> This way we could handle all cases instead of throwing an exception during a
> merge when we encounter a multi valued DVs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
