[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125716#comment-13125716
]
Pavel Yaskevich commented on CASSANDRA-1034:
--------------------------------------------
Can you please define what do you mean by "pure token"? Aren't we supposed to
generate token from key in all situations except initial token in config and
middle point between tokens? So if you do a range slice using tokens instead of
keys TokenFactory.fromString will force you to use correctly serialized token
data which will also include key.
bq. It's error-prone and make coding more complicated. We're merging object
that are not the same thing etc...
If token is generated from key than for me it's natural to have a key as
member. The thing is that you are enable to create a "pure" token, Partitioner
will always give you a Token with valid key except for midpoint method so if
partitioner is used to generate tokens you are guaranteed to have a valid key
in the resulting token instance.
bq. It's a ~300K patch. Sure it's mostly simple changes, but it's still that
many changes that could introduce a typo somewhere that causes a bug.
The same thing I can say about your set of patches - it's 198 KB. Aren't we
writing tests to catch such bugs?
> 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: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.1
>
> Attachments:
> 0001-Make-range-accept-both-Token-and-DecoratedKey.patch,
> 0002-LengthPartitioner.patch, 1034-1-Generify-AbstractBounds-v3.patch,
> 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.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
