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

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-1034:
-------------------------------------------

bq. it's very convenient to be able to use the "natural" compareTo to compare those two kinds of DK

In particular, we generate (Token, null) DKs for range scans, at least in part because Hadoop thinks in terms of TokenRanges instead of DecoratedKeyRanges.  (Presumably it is still ok to assume that a partitioner generates many more tokens than there are nodes in the cluster; if not, this would need to change.)

We might be able to still do this, if we just say that DK(T, null) always sorts before DK(T, non-null-key) for any given Token T.

I still suspect we're using DK in some places where Token is all we really need.

> 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
>            Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.