cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
Date Mon, 21 Nov 2011 21:18:52 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message