You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Piotr Kołaczkowski (JIRA)" <ji...@apache.org> on 2014/09/15 09:07:33 UTC

[jira] [Comment Edited] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner

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

Piotr Kołaczkowski edited comment on CASSANDRA-7020 at 9/15/14 7:07 AM:
------------------------------------------------------------------------

{quote}
-9223372036854775808 is min value for ssmtable scanned so putting it in where clause of select statement behaves as select * from test{quote}

And this is illogical and surprising behavior because the tokens of the returned rows do not satisfy the condition in the query. No token is ever smaller than min token, therefore the only correct answer is empty row set here.

Nevertheless, if it were to wrap-around, it needs to wrap-around always consistently, not just for the min token. So actually any query not restricting the token range from both sides should return all rows (it doesn't work like this now - the case described in the ticket is the only case, when token comparison wraps-around).

Actually I like the idea of never wrapping around in CQL, because it doesn't make token comparisons "special" and treats them just as any other integer comparison. Integer comparison is pretty well-defined concept in mathematics - I see no reason it should work differently for tokens in cassandra. 


was (Author: pkolaczk):
{quote}
-9223372036854775808 is min value for ssmtable scanned so putting it in where clause of select statement behaves as select * from test{quote}

And this is illogical and surprising behavior because the tokens of the returned rows do not satisfy the condition in the query. No token is ever smaller than min token, therefore the only correct answer is empty row set here.

Nevertheless, if it were to wrap-around, it needs to wrap-around always consistently, not just for the min token. So actually any query not restricting the token range from both sides should return all rows.

Actually I like the idea of never wrapping around, because it doesn't make token comparisons "special" and treats them just as any other integer comparison. 

> Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
> -----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7020
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: cassandra 2.0.6-snapshot 
>            Reporter: Piotr Kołaczkowski
>            Assignee: Marko Denda
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
>  key | value
> -----+----------
>    5 |   eeeeee
>   10 |        j
>    1 |     aaaa
>    8 | hhhhhhhh
>    2 |      bbb
>    4 |       dd
>    7 |     gggg
>    6 |      fff
>    9 |     iiii
>    3 |    ccccc
> {noformat}
> Expected: empty result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)