[
https://issues.apache.org/jira/browse/LUCENE-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward resolved LUCENE-10377.
------------------------------------
Fix Version/s: 9.1
10.0 (main)
Resolution: Fixed
> Replace 'sortPos' parameter in SortField.getComparator()
> --------------------------------------------------------
>
> Key: LUCENE-10377
> URL: https://issues.apache.org/jira/browse/LUCENE-10377
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Major
> Fix For: 9.1, 10.0 (main)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SortField.getComparator() takes two parameters: the number of hits we are
> collecting, so that the comparator can size its internal priority queue; and
> the position of this sortfield in the overall sort. This second parameter is
> only actually used to determine whether or not the SortField should enable
> various skipping operations, building comparative iterators etc. However,
> it's not clear from the API that this is why it is passed, and as a
> consequence all sorts of consumers of this API faithfully pass through their
> sort positions even when they aren't actually using skipping at all. In
> particular, CheckIndex does this when checking index sorts, and this in fact
> leads to a bug, where it will attempt to build skipping structures over
> fields from 8x-created indexes that did not have the same type constraints
> that 9x indexes do and incorrectly throw an error.
> I think we should replace this second parameter with a simple boolean,
> `enableSkipping`, that the TopHits collectors can pass as `true` for the
> first sortfield. Other APIs that use sorts but not skipping, like CheckIndex
> or the grouping collectors, can always pass `false` so we don't waste time
> building skipping structures that never get used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
