[ https://issues.apache.org/jira/browse/LUCENE-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666821#comment-15666821 ]
Michael McCandless commented on LUCENE-7537: -------------------------------------------- Thanks [~jim.ferenczi], this looks very close! For {{SimpleText}}, could we use "multi_valued_string" instead of "sorted_string" to describe it in the segment info format? Can we also name the new tests with "multi valued" instead of "sorted", e.g. {{testBasicSortedLong}} --> {{testMultiValuedLong}}? Can we change this: {noformat} throw new IllegalStateException("Unexpected SortedNumericSortField type: " + sortField.getType()); {noformat} to this?: {noformat} throw new IllegalStateException("Unexpected SortedNumericSortField " + sortField); {noformat} Just so we get more information if we ever do hit these exceptions... Instead of: {noformat} static final int VERSION_CURRENT = 1; {noformat} Can you introduce a separate constant for the value {{1}}? E.g.: {noformat} static final int VERSION_MULTI_VALUED_SORT = 1; static final int VERSION_CURRENT = VERSION_MULTI_VALUED_SORT; {noformat} It just gives us a bit more info about why the format change happened. Hmm, I see we have no back-compat testing of sorted indices ... I'll open an issue to fix that. Once this change is released to the wild (6.4.0), we have to improve that to include multi-valued sort ... I'll do that too. > 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 > Fix For: master (7.0), 6.4 > > Attachments: LUCENE-7537.patch, LUCENE-7537.patch, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org