[
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)
