[
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
