[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155934#comment-13155934
]
Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------
bq. Help me understand this patchset a different way: which is the part without
which CASSANDRA-1600 is impossible?
CASSANDRA-1600 requires that the row key range requested be known by
CFS.getRangeSlice/search, while today it only gest the corresponding tokens.
We could possibly do what your first patch for CASSANDRA-1600 did and add the
keys separately. You'll have to deal with wrapping and such, but that's
probably doable.
What this patchset does is make getRangeSlice/search actually take keys, so
this greatly simplify CASSANDRA-1600. But CASSANDRA-1600 is probably doable
without this, it's just the logical first step before getting a clean
implementation. Now for the specific parts, as said we need to be able to have
keys for getRangeSlice/search, which basically require the bulk of this
patchset (i.e. for CASSANDRA-1600, we could still have DecoratedKey.compareTo()
to only compare the tokens and not the keys, but that's probably it)
But truth being told, CASSANDRA-1600 is by far not my main motivation for this.
My main motivation is CASSANDRA-1684. For the latter, if we want to do it
'natively', we will have lots of key having the same token, so this ticket is
an absolute requirement before even getting started. And there is also the
problem of md5 collision :)
> 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
