cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Sat, 26 Mar 2011 10:15:05 GMT


Stu Hood commented on CASSANDRA-1034:

I was reaaally hoping we could subclass here... adding RingPosition leads to explicit conversions
scattered all over that end up obscuring  implicit conversions.

The hairiest part of subclassing would be renaming all of our Token subclasses with DecoratedKey
subclasses, but it cleans up unnecessary references: for example, for a DecoratedKey for ByteOrderPartitioner
or LocalPartitioner you have:
   BytesToken token;
      ByteBuffer token;
   ByteBuffer key;
... while with subclassing you could save two object references:
   ByteBuffer keyAndToken;

Also, the Comparable dilemma is relatively straightforward with subclassing: Token implements
Comparable<Token>, the subclasses override, call, and if their superclass
is equal, fall back to instanceof(myclass) to see whether they can compare the key data.

> 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: 0.8
>         Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.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:

View raw message