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

Benjamin Lerer updated CASSANDRA-14684:
---------------------------------------
    Description: 
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]

When running a CQL query where we filter on a token compared to 
-9223372036854775808 (the minimum value for a long), the filter appears to have 
no effect.

For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808 
LIMIT 3;
system.token(user_id)
 -----------------------
  -9223371814601747988
  -9223371814601747988
  -9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the 
comparison, the results appear the same.

In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected: 
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807 
LIMIT 3;
system.token(user_id)
-----------------------
(0 rows)
{code}
 
Additional information for newcomers:

Some checks should be added into {{TokenRestriction}} for the different type of 
restrictions when an invalid value is found. 
The unit tests should be added within {{SelectOrderedPartitionerTest}}


  was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]

When running a CQL query where we filter on a token compared to 
-9223372036854775808 (the minimum value for a long), the filter appears to have 
no effect.

For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808 
LIMIT 3;
system.token(user_id)
 -----------------------
  -9223371814601747988
  -9223371814601747988
  -9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the 
comparison, the results appear the same.

In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected: 
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807 
LIMIT 3;
system.token(user_id)
-----------------------
(0 rows)
{code}
 
+ Additional information for newcomers:+

Some checks should be added into {{TokenRestriction}} for the different type of 
restrictions when an invalid value is found. 
The unit tests should be added within {{SelectOrderedPartitionerTest}}



> Queries with a clause involving tokens and Long.MIN_VALUE include rows 
> incorrectly
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-14684
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/CQL
>            Reporter: George Boyle
>            Priority: Low
>              Labels: lhf
>             Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to 
> -9223372036854775808 (the minimum value for a long), the filter appears to 
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808 
> LIMIT 3;
> system.token(user_id)
>  -----------------------
>   -9223371814601747988
>   -9223371814601747988
>   -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the 
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as 
> expected: 
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <= 
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> -----------------------
> (0 rows)
> {code}
>  
> Additional information for newcomers:
> Some checks should be added into {{TokenRestriction}} for the different type 
> of restrictions when an invalid value is found. 
> The unit tests should be added within {{SelectOrderedPartitionerTest}}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to