[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154533#comment-13154533
]
Sylvain Lebresne commented on CASSANDRA-1034:
---------------------------------------------
No, no, the patch does use the same think. I merely said that the patch does
some attempt at a better encapsulation, as it seems better to use the
Token.{upper|lower}BoundKey to creates those fake keys that inlining the call
to the constructor all over the code (which we do now). It makes the use of
null more of an internal detail of DecoratedKey (not completely, granted, but
it's a little bit better). It also makes it simpler to check we don't
accidentally construct a DK with a null key by accident (the goal of the
assertion in the first DK constructor in the patch).
But let it be clear that I'm not making any claim that this patch "cleans" some
ugliness in the current code. It mainly try to solve the problem at hand, which
is basically to be able to do range_slices and getting the right result even
when multiple keys have the same token.
This is not saying it wouldn't be good to fix any current ugliness at the same
time if possible, but in truth, I don't find that using special DK to represent
special keys is such an ugly hack (not either claiming it's super beautiful, I
just don't have a particular hatred of this). Besides, I don't have tons of
ideas to fix the issue at end (the priority) and make the code clearly cleaner.
And I do think that whatever ugliness the current have, this patch doesn't make
it worst.
Anyway, I'll try to see if I can improve the encapsulation of the
Token.{upper|lower}BoundKey representation and see if I can come with something
slightly cleaner.
> 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.patch,
> 0002-Remove-assumption-that-token-and-keys-are-one-to-one.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
