[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125848#comment-13125848
]
Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------
bq. But the whole point of the ticket is to remove this concept. Are you saying
that can't be guaranteed?
There is a misunderstanding. The whole point of this ticket is to *enforce*
this concept. A token is a range, a segment on the ring, there is nothing we
can do about it. It's like saying the point of the ticket is to remove the
concept that a segment is different from a point.
I'm happy to discuss that, and that is clearly where we should start, but I'm
pretty sure that the *problem* we want to fix is that the current code is
pretending than a segment is equal to a point. The current code is pretending
that a token t is the same thing than a key having this token. This only work
if there is only one key have a given token, otherwise it's buggy, you identify
all keys having the same token as equal, that is the problem.
And saying that you'll change the comparison of DK to include the key and
pretending that a token is the same thing that some fictive key that as far as
key comparison is concerned would be before any key having the token (which is
*exactly* what Pavel's patch is doing) doesn't work either. As I've said
earlier with examples.
I'm saying that the right way to fix is to make the code treats Token as a
segment (because you know, that's what it is) and a key as a point. Now that,
imho, is not of a debatable nature: it's either true or false (and imho clearly
true but maybe i'm completely stupid). But at the very least we should agree on
that first, even before thinking about how we will code it.
Then, once we agree on the problem, there is the question of how we do it. And
then, my second argument is that shoving a token (a segment) and a (decorated)
key (a point) into the same class (that we would happen to call Token) is, why
probably "possible", likely an error-prone, confusing and frankly ugly idea.
You can create a class representing both a segment and point, having it work
correctly underneath and write code using that, but it will unlikely be
beautiful nor easy to use. But it's "possible".
> Remove assumption that Key to Token is one-to-one
> -------------------------------------------------
>
> Key: CASSANDRA-1034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1034
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stu Hood
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.1
>
> Attachments:
> 0001-Make-range-accept-both-Token-and-DecoratedKey.patch,
> 0002-LengthPartitioner.patch, 1034-1-Generify-AbstractBounds-v3.patch,
> 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.patch,
> 1034_v1.txt, CASSANDRA-1034.patch
>
>
> get_range_slices assumes that Tokens do not collide and converts a KeyRange
> to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and
> would lead to a very weird heisenberg.
> Converting AbstractBounds to use a DecoratedKey would solve this, because the
> byte[] key portion of the DecoratedKey can act as a tiebreaker.
> Alternatively, we could make DecoratedKey extend Token, and then use
> DecoratedKeys in places where collisions are unacceptable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
