iverase commented on code in PR #12528:
URL: https://github.com/apache/lucene/pull/12528#discussion_r1334028608
##########
lucene/core/src/java/org/apache/lucene/index/PointValues.java:
##########
@@ -228,6 +228,22 @@ public enum Relation {
CELL_CROSSES_QUERY
};
+ /** Math states for current value. */
+ public static final class MatchState {
+ private MatchState() {}
+
+ /** Invalid state */
+ public static final int INVALID = -1;
+ /** Packed value matches the range in this dimension */
+ public static final int MATCH = 0;
+ /** Packed value is too low in this SORTED or NON-SORTED dimension */
+ public static final int LOW = 1;
+ /** Packed value is too high in SORTED dimension */
+ public static final int HIGH_IN_SORTED_DIM = 2;
+ /** Packed value is too high in NON-SORTED dimension */
+ public static final int HIGH_IN_NON_SORTED_DIM = 3;
+ }
Review Comment:
My main concern here is that the concept of SORTED dimension does not exist
in the PointValues API. If you have a look to the javadocs when visiting a leaf
node:
```
/**
* Called for all documents in a leaf cell that crosses the query. The
consumer should
* scrutinize the packedValue to decide whether to accept it. In the 1D
case, values are visited
* in increasing order, and in the case of ties, in increasing docID
order.
*/
```
It only constraints the 1D case but in higher dimensions there is no
constraint how data is visited. The concept of SORTED dimension sounds to me an
implementation detail that should not be leaked to the public API.
--
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: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
