[jira] [Comment Edited] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly

2018-08-31 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna edited comment on CASSANDRA-14684 at 8/31/18 2:25 PM:
---

It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for [reasons described in the getToken() 
method|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213].

{code}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code}

So good point [~benedict], we should probably document that beyond the comment 
in the code.


was (Author: jeromatron):
It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for [reasons described in the getToken() 
method|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213].

{code}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code}

> 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
>Reporter: George Boyle
>Priority: Major
>
> [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}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly

2018-08-31 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna edited comment on CASSANDRA-14684 at 8/31/18 2:24 PM:
---

It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for [reasons described in the getToken() 
method|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213].

{code}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code}


was (Author: jeromatron):
It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for reasons described in the getToken() method.

{code}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code} 

See 
[here.|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213]

> 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
>Reporter: George Boyle
>Priority: Major
>
> [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}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly

2018-08-31 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna edited comment on CASSANDRA-14684 at 8/31/18 2:23 PM:
---

It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for reasons described in the getToken() method.

{code}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code} 

See 
[here.|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213]


was (Author: jeromatron):
It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for reasons described in the getToken() method.

{code:java}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code} 

See 
[here.|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213]

> 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
>Reporter: George Boyle
>Priority: Major
>
> [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}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly

2018-08-31 Thread Jeremy Hanna (JIRA)


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

Jeremy Hanna edited comment on CASSANDRA-14684 at 8/31/18 2:22 PM:
---

It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

However reading through the code, even though the [minimum value set for 
murmur3 is 
Long.MIN_VALUE|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L43],
 we exclude that for reasons described in the getToken() method.

{code:java}
/**
 * Generate the token of a key.
 * Note that we need to ensure all generated token are strictly bigger than 
MINIMUM.
 * In particular we don't want MINIMUM to correspond to any key because the 
range (MINIMUM, X] doesn't
 * include MINIMUM but we use such range to select all data whose token is 
smaller than X.
 */
{code} 

See 
[here.|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java#L208-L213]


was (Author: jeromatron):
It depends on the partitioner.  For the default murmur3 partitioner, the range 
is -2^63^ to +2^63^-1 which is Long.MIN_VALUE to Long.MAX_VALUE.  So it should 
work up to those boundaries.  For the random partitioner which is an md5 based 
hash, it's 0 to 2^127-1 but I doubt you're using that.

> 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
>Reporter: George Boyle
>Priority: Major
>
> [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}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly

2018-08-31 Thread Benedict (JIRA)


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

Benedict edited comment on CASSANDRA-14684 at 8/31/18 2:03 PM:
---

This query should probably be rejected, as Long.MIN_VALUE is not a valid token.

Do we actually document this externally anywhere?  If not that seems like a 
major oversight, and perhaps we should transparently treat it as the nearest 
valid token that maintains the semantics of the operator.


was (Author: benedict):
This query should probably be rejected, as Long.MIN_VALUE is not a valid token.

> 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
>Reporter: George Boyle
>Priority: Major
>
> [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}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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