gsmiller commented on a change in pull request #443:
URL: https://github.com/apache/lucene/pull/443#discussion_r752298802
##########
File path:
lucene/facet/src/java/org/apache/lucene/facet/taxonomy/OrdinalMappingLeafReader.java
##########
@@ -107,6 +113,64 @@ public BytesRef binaryValue() {
}
}
+ private class OrdinalMappingSortedNumericDocValues extends
FilterSortedNumericDocValues {
+ private final IntArrayList currentValues;
+ private int currIndex;
+
+ OrdinalMappingSortedNumericDocValues(SortedNumericDocValues in) {
+ super(in);
+ currentValues = new IntArrayList(32);
+ }
+
+ @Override
+ public boolean advanceExact(int target) throws IOException {
+ boolean result = in.advanceExact(target);
+ if (result) {
+ reloadValues();
+ }
+ return result;
+ }
+
+ @Override
+ public int advance(int target) throws IOException {
+ int result = in.advance(target);
+ if (result != DocIdSetIterator.NO_MORE_DOCS) {
+ reloadValues();
+ }
+ return result;
+ }
+
+ @Override
+ public int nextDoc() throws IOException {
+ int result = in.nextDoc();
+ if (result != DocIdSetIterator.NO_MORE_DOCS) {
+ reloadValues();
+ }
+ return result;
+ }
+
+ @Override
+ public int docValueCount() {
+ return currentValues.elementsCount;
+ }
+
+ private void reloadValues() throws IOException {
+ currIndex = 0;
+ currentValues.clear();
+ for (int i = 0; i < in.docValueCount(); i++) {
+ currentValues.add(ordinalMap[(int) in.nextValue()]);
Review comment:
@rmuir Hmm, yeah interesting. We have a couple cases related to taxonomy
faceting now where we're explicitly storing ordinals in a dv field, but not
using SORTED_SET since the "mapping" back to the string values is handled by
the taxonomy index (this change and LUCENE-10122). I wonder if there are any
other cases like this outside of our taxonomy faceting? I wonder if it would
make any sense at all to consider a new dv field type for explicitly storing
ordinals? I suspect we don't have enough general use-cases to support such an
idea, but just throwing it out there for conversation. Such a field could make
assumptions about the data that would probably allow it to be more efficient,
and some of the logic we're currently handling ourselves (e.g., de-duping)
could be done by the field type. Like I said, probably not enough real-world
use-cases to justify adding a new type, but figured I'd float the suggestion
anyway for input.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
