[
https://issues.apache.org/jira/browse/CASSANDRA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746121#action_12746121
]
Jonathan Ellis commented on CASSANDRA-242:
------------------------------------------
This fits my brain much better when I think of the collationkey as the key
decoration like the bigint from RP, btw.
(and actually treating it that way could probably improve performance on
memtable flush, where we do a ton of compares to sort the keys.)
moving to (token, key) instead of String decoratedkey is sounding better and
better to me. for one it is clear from static typing that String != (Token,
String) which you have to be really careful with in the current codebase.
> 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.
