[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159307#comment-13159307
]
Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------
bq. I mean that straight addition is a weak hashcode combination since X + Y is
the same as Y + X. "return Objects.hashCode(X, Y)" is an easy way to do it
"right" with no more code than the weak approach. Doesn't matter much here but
it's good practice imo.
Make sense. I made the DK hashcode be only based on the key hashcode though
(since the token is just a cached value for getToken() :)). The hashCode method
of Token.KeyBound don't use Objects.hasCode(), but I really think that in that
case it doesn't matter at all and it avoids the boxing of the boolean. I can
change it though if that's the only problem remaining.
bq. Another nit: should we be using a enum for RowPosition.kind?
What do you mean exactly by that? Are you talking of the kind use in
RowPositionSerializer? To have an enum to distinguish between DK and
Token.KeyBound instance of doing the instanceof? If so why not, but I'm not
sure it buys us anything.
> 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: 1.1
>
> Attachments: 0001-Generify-AbstractBounds-v2.patch,
> 0001-Generify-AbstractBounds.patch,
> 0002-Remove-assumption-that-token-and-keys-are-one-to-one-v2.patch,
> 0002-Remove-assumption-that-token-and-keys-are-one-to-one.patch,
> 0003-unit-test-v2.patch, 0003-unit-test.patch, 1034_v1.txt,
> CASSANDRA-1034.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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
