DonalEvans commented on a change in pull request #6831:
URL: https://github.com/apache/geode/pull/6831#discussion_r702144208
##########
File path:
geode-apis-compatible-with-redis/src/main/java/org/apache/geode/redis/internal/data/RedisSortedSet.java
##########
@@ -377,6 +382,25 @@ long zrevrank(byte[] member) {
return scoreSet.size() - scoreSet.indexOf(orderedSetEntry) - 1;
}
+ ImmutablePair<Integer, List<byte[]>> zscan(Pattern matchPattern, int count,
int cursor) {
+ // No need to allocate more space than it's possible to use given the size
of the sorted set. We
+ // need to add 1 to zcard() to ensure that if count > members.size(), we
return a cursor of 0
+ long maximumCapacity = 2L * Math.min(count, zcard() + 1);
+ if (maximumCapacity > Integer.MAX_VALUE) {
+ LogService.getLogger().info(
+ "The size of the data to be returned by zscan, {}, exceeds the
maximum capacity of an array. A value for the ZSCAN COUNT argument less than {}
should be used",
+ maximumCapacity, Integer.MAX_VALUE / 2);
+ throw new IllegalArgumentException("Requested array size exceeds VM
limit");
+ }
+ List<byte[]> resultList = new ArrayList<>((int) maximumCapacity);
+ do {
+ cursor = members.scan(cursor, 1,
Review comment:
Yeah the COUNT/MATCH interaction isn't ideal. From Redis' SCAN
documentation:
> It is important to note that the MATCH filter is applied after elements
are retrieved from the collection, just before returning data to the client.
This means that if the pattern matches very little elements inside the
collection, SCAN will likely return no elements in most iterations.
so it'd be a significant departure from Redis' way of doing things if we
kept the old implementation (even if it's better).
--
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]
