cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Mon, 28 Nov 2011 14:50:40 GMT


Jonathan Ellis commented on CASSANDRA-1034:

+1 on the KeyBound approach.  This is exactly what I was hoping for.

Returning to a minor point:

bq. bq. I don't see a good reason to not use a "real" hashcode implementation (Objects.hashCode
is useful here)

bq. Not sure I follow but ByteBuffer.hashCode() does hash the content of the buffer if that
was what you meant.

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.

Another nit: should we be using a enum for RowPosition.kind?

Meta observation: I'm glad we're not doing this a week before freeze. :)
> Remove assumption that Key to Token is one-to-one
> -------------------------------------------------
>                 Key: CASSANDRA-1034
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message