cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
Date Wed, 26 Aug 2015 08:22:46 GMT

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

Sylvain Lebresne commented on CASSANDRA-7020:
---------------------------------------------

Not so fast: this patch is broken and I think more consideration of this change is required.

As explain by the code comment, the main intent of the condition is to handle case like \[a,
b\] where b < a. The condition of the patch ({{(startToken.isMinimum() && endToken.isMinimum()
&& (cmp > 0 || (cmp == 0)))}} doesn't handle that at all anymore (it *only* handle
the min token). Condition that is, btw, unecessary complex since {{startToken.isMinimum()
&& endToken.isMinimum()}} *implies* that {{cmp == 0}}.

Further, the original reason of this special case is that the min token acts both as a min
and a max for token ranges. This is the way it works internally and that's the reason it has
been done that way in CQL as the expectation was that client code would probably mimick the
way token range are handled in C* anyway (and that's true of the java driver in particular
which does represent the full ring as the range of (minToken, minToken]). This means in turn
that querying everything in the range (minToken, minToken] returns the whole ring and that's
the reason for the results on this ticket.

Now, I'm not trying to say that all this is very intuitive, it's not, and it is to some extend
inconsistent. What I'm saying however is that:
# the fact that the token ring in cassandra isn't a total order (the min token is both the
min and max) is a bit of a mismatch with CQL, but we still want to support token somehow and
that is bound to be imperfect.
# whether the current solution is the best one or not, changing it is a breaking change and
that requires careful consideration. In particular, it would not be appropriate to do so in
2.1 at this point.

Now, my personal opinion is that it's not worth bothering with changing this behavior at this
point. Yes, the example of the description is undoubtedly surprising the first time you encounter
it, but at the same time, the min token *is* a special token in Cassandra and if you work
with tokens, you'd better learn that sooner than later. Or to put it another way, changing
this might be more consistent for CQL, but it won't be perfect either since it will mismatch
with how tokens actually work in Cassandra, so between 2 imperfect solutions, I'd rather stick
with the one that don't imply breaking backward compatibility. I don't feel terribly strongly
about it though and that's certainly up for debate.



> 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
>             Fix For: 2.1.x
>
>         Attachments: 7020.txt
>
>
> {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)

Mime
View raw message