[ 
https://issues.apache.org/jira/browse/GEODE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donal Evans resolved GEODE-9427.
--------------------------------
    Fix Version/s: 1.15.0
       Resolution: Fixed

The Redis documentation states that *SCAN behaviour is undefined for CURSOR 
values other than 0 or the value returned by the previous *SCAN command. Given 
that it is not possible for a *SCAN command to return a value greater than 
Integer.MAX_VALUE, any value greater than that is not a valid CURSOR and so the 
behaviour of the command is undefined.

For this reason, it was decided that returning an error for CURSOR values 
greater than Long.MAX_VALUE was an acceptable compromise that prevented the 
need to create BigInteger objects that are only used for corner-case input 
validation while still allowing behaviour that's the same as native Redis for 
all valid inputs.

> Radish HSCAN implementation does not accept values for CURSOR argument that 
> match Redis
> ---------------------------------------------------------------------------------------
>
>                 Key: GEODE-9427
>                 URL: https://issues.apache.org/jira/browse/GEODE-9427
>             Project: Geode
>          Issue Type: Bug
>          Components: redis
>    Affects Versions: 1.15.0
>            Reporter: Donal Evans
>            Assignee: Donal Evans
>            Priority: Major
>             Fix For: 1.15.0
>
>
> The HSCAN command takes an argument, CURSOR, which in native Redis can be any 
> value between -18446744073709551615 and 18446744073709551615 (the maximum 
> value of an unsigned long). The Radish implementation of HSCAN only accepts 
> values in the range {{Integer.MIN_VALUE}} -> {{Integer.MAX_VALUE}} and 
> returns an error if values outside this range are used.
> The Radish HSCAN implementation should be modified to accept the same range 
> of values as Redis. Examples of this can be found in the implementations of 
> the currently unsupported SCAN and SSCAN commands.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to