[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-1034:
----------------------------------------
Attachment: Remove-assumption-that-key-and-token-are-one-to-one-v2.patch
I realize that this is a little more subtle than I first though.
You just cannot compare a Token and a DecoratedKey simply, because a Token is
actually a range of keys. Hence dealing with a Range that mixes Token and
DecoratedKey correctly is doable, but a bit complicated (typically, it involves
declaring multiple different comparison functions). To take quick example,
consider that if you mix DK and Token, you must have the following that stands:
{noformat}
(T(2), T(8)] should not contain DK(T(2), "foo") => DK(T(2), "foo") < T(2)
[T(2), T(8)] should contain DK(T(2), "foo") => DK(T(2), "foo") >= T(2)
{noformat}
So there is no way to write a compareTo() function dealing with both DK and
token.
So I think that it will be simplest to not mix DK and Token in the same ranges.
We'll have ranges of Token (for everything related to ring management) and
ranges of DK (for rangeSlice and scan). This is what the patch does (and the
patch 'generify' AbstractBounds, Range and Bounds (a fair part of the patch) to
keep type information around and avoid unnecessary casts all over the place).
We still want to make a rangeSlice/scan over a range of token. To do that, we
simply convert a range of Token to a range of DK. This involves declaring for a
given token a smallest key and biggest key, and this in turn comes a slight
complication related to the minimum token, but the detail are in the docstrings
of the patch. I am reasonably confident on that new patch.
(Note that this patch is much bigger than the previous one, but this is mostly
due to the generification of Range)
> 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: 0.8
>
> Attachments:
> 0001-Make-range-accept-both-Token-and-DecoratedKey.patch,
> 0002-LengthPartitioner.patch, 1034_v1.txt,
> Remove-assumption-that-key-and-token-are-one-to-one-v2.patch
>
>
> 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
