You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/03/03 20:12:37 UTC

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

     [ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne updated CASSANDRA-1034:
----------------------------------------

    Attachment: 0002-LengthPartitioner.patch
                0001-Make-range-accept-both-Token-and-DecoratedKey.patch

Attaching a patch that I believe solves this. It makes Range accept both Token and DecoratedKey and makes those two compare together correctly.

It introduces a new marker interface (RingPosition) instead of making DecoratedKey extends Token (for reason explained in the comments of RingPosition but to sum up: I think it's cleaner).

The second patch attached is just a stupid partitioner that use for token the length of the key. It's just for testing and not meant for inclusion. But this shows that with the first patch, you can do correct range query that go from 'the middle of a token' to the 'middle of another one'.

An important note is that this breaks the serialization unit tests, because now an AbstractBounds can use decoratedKeys, and thus serialized AbstractBounds are incompatible with previous version. Not sure how to deal with that though, I though we had a plan for dealing with that but I'll admit I don't remember the details.

> 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
>         Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.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