Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 25 Mar 2011 19:26:05 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1282114436.12062.1301081165828.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to
 Token is one-to-one
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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