[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011373#comment-13011373
]
Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------
bq. Less of a fan of pretending that Tokens and DK are equal if the token
component of DK is equal. Shouldn't we force caller to ask
Token.equals(DK.token) if that's what they mean? As you pointed out in RP
docstring, there is not an is-a relationship there.
The thing is, we need them to be equal for compareTo() (because we can't have
token > keys nor token < keys, otherwise that would mess up our ranges). Then
for the equals, the motivation is summed up by the Comparable documentation:
{noformat}
It is strongly recommended (though not required) that natural orderings be
consistent with equals. This is so because sorted sets (and sorted maps)
without explicit comparators behave "strangely" when they are used with
elements (or keys) whose natural ordering is inconsistent with equals. In
particular, such a sorted set (or sorted map) violates the general contract for
set (or map), which is defined in terms of the equals method.
{noformat}
And I do fear that we would get something inconsistent at some point.
But I'm not a super fan either, just felt the less evil of the two choices.
I'm happy with suggestion though and I'll work out the other remarks.
> 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
>
>
> 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
