[
https://issues.apache.org/jira/browse/CASSANDRA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746188#action_12746188
]
Stu Hood commented on CASSANDRA-242:
------------------------------------
I don't think we need to break disk compatibility in order to get this merged:
we would only need to break disk compatibility to replace decoratedKeys with
the (token, key) tuple. This patch (the midpoint method itself and the change
to COPP) will need to happen either way, and isn't blocked by the disk format
change.
In order for the midpoint method to be useful for CASSANDRA-342, we just need
to implement a RangeCommand which takes Tokens, which can be accomplished
(sloppily, with a comparator to compare decoratedKeys and Tokens).
The SSTable tuple/index change would make that RangeCommand more efficient, and
as you mentioned, will definitely speed up sorting, because sorting of the
tuples can ignore the String comparison of the Key itself unless the Tokens are
equal. We would probably be better served by blocking 0.4 long enough to get
CASSANDRA-389 in, and then worrying about this optimization later.
If you still want to bring it up on the list we can, but I propose we:
1. Merge this,
2. Create a ticket for the death of decoratedKeys (possibly dependent on
CASSANDRA-389),
3. Create a ticket for the Token RangeCommand (possibly dependent on 2, if we
don't want to implement the sloppy Comparator for decoratedKey to Token).
> Implement method to "evenly" split a Range
> ------------------------------------------
>
> Key: CASSANDRA-242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-242
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.4
> Reporter: Stu Hood
> Assignee: Stu Hood
> Fix For: 0.4
>
> Attachments: CASSANDRA-242.diff, CASSANDRA-242.diff,
> CASSANDRA-242.diff, CASSANDRA-242.diff
>
>
> Two tickets currently depend on being able to deterministically split a Range
> object into two "even" Ranges.
> This can be accomplished with RandomPartitioner/BigIntegerToken by taking the
> average of the tokens, but the OrderPreservingPartitioner/StringToken
> implementation uses a Java Collator to define the sort order of Tokens, which
> means that they are not necessarily sorted in byte/char order.
> Collator.getCollationKey(String).toByteArray() gets you a sortable byte
> array, but there is no publicly accessible API for converting a similar byte
> array back into a String.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
