cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Fri, 25 Mar 2011 19:26:05 GMT

    [ 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

Mime
View raw message