[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------

bq. One way to remove toSplitValue would be to use DecoratedKey everywhere;

I'm not saying it's not possible, but I think this is overkill (in the changes it involves). Moreover, all the code that deals with topology really only care about token. That's the right abstraction for those part of the code. So I really (really) doubt using decorated key everywhere would be cleaner. Of course, anyone is free to actually do the experiment and prove me wrong. I also don't think it would remove the need for splitValue, it would just maybe call it differently.

bq. The equivalent of today's Token is a DecoratedKey for that token with a null key

This is only true today because we assume key and token are one-to-one. The goal is to change that. If multiple keys can have the same token (by definition the token is really the hash of a key), then the statement above is false. If a token correspond to an infinite set of key (with is the case with md5 btw, we just ignore it), then replacing a token by given key *cannot* work.

Overall, it could be that there is better way to do this, but having spend some time on this, I have a reasonable confidence on that it fixes the issue at hand without being too disruptive (which is not saying there isn't a few points here and there that couldn't be improved).

> 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: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.0
>
>         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
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira