[ 
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

        

Reply via email to