Open bugmakerrrrrr opened 7 hours ago
@reta You may be interested in this. Any thoughts?
And if we want to make values ordered in one doc, maybe we can flip the sign bit before sending the value to Lucene, and re-flip the sign bit when reading from sorted numeric doc value, this can benefit max & min multi-value mode. But this is a breaking change, we can do it according to the index version.
Thanks @bugmakerrrrrr , I should be able to get into it next week, unless you want to pick it up? :-)
Describe the bug
Recently, I worked on supporting the reuse of doc values to reconstruct the source field and avoid storing it. Then, I found that the number fields are ordered when fetching from sorted numeric doc values except the unsigned long field. This is because Lucene treats it as a signed number. IMO, this is not a problem in many situations, but if an unsigned long field has multiple values per doc, the sort result may be wrong, because in the current implementation, the sort mode uses signed long to pick the value.
Related component
Search
To Reproduce
Expected behavior
The sort result should be correct.
Possible solution: create a dedicated
UnsignedLongMultiValueMode
for unsigned long, then convert the normal mode to unsigned long mode and use the converted mode to pick the sort value inUnsignedLongValuesComparatorSource
.Additional Details
Plugins Please list all plugins currently enabled.
Screenshots If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):
Additional context Add any other context about the problem here.