[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011386#comment-13011386
]
Jonathan Ellis commented on CASSANDRA-1034:
-------------------------------------------
I understand the Comparable docs, but
- that's primarily concerned w/ compareTo + equals b/t members of the same class
- it's valid to say "these are tied for sorting purposes, and yet they are not
equal"
In other words I'm more worried about subtle bugs if we allow the equals, than
if we don't. :)
The Map example is a good one -- if I set
map[token(1)] = foo
map[dk(1, 1)] = bar
I would expect two map entries, not one. (If you want one, you explicitly use
asToken, then there is no ambiguity.)
How about if we add an assert to both equals to make sure we don't pass in the
other kind of object?
> 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
