[
https://issues.apache.org/jira/browse/CASSANDRA-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038420#comment-13038420
]
Sylvain Lebresne commented on CASSANDRA-1978:
---------------------------------------------
What about computing the token from the key for CASSANDRA-2003 ?
Right now it's a legit things to do to walk all keys until CASSANDRA-1034.
After CASSANDRA-1034 it will have a risk to miss some keys, but we'll then have
this problem with hadoop too. But then I'm not sure the fix attached here is
the right one. I think the right fix will be to only allow keys in
range_slices, but all to specify if we're asking for a bound or a range. That
is, changing KeyRange to something like:
{noformat}
struct KeyRange {
1: required binary start_key,
2: required binary end_key,
3: required boolean start_inclusive,
5: required i32 count=100
}
{noformat}
Anyway, we should probably defer that to later, but unless I'm missing
something this shouldn't block CASSANDRA-2003.
> get_range_slices: allow key and token to be interoperable
> ---------------------------------------------------------
>
> Key: CASSANDRA-1978
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1978
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Kelvin Kakugawa
> Assignee: Kelvin Kakugawa
> Priority: Minor
> Fix For: 0.8.1
>
> Attachments:
> 0001-CASSANDRA-1978-allow-key-token-to-be-interoperable-i.patch
>
>
> problem: get_range_slices requires two keys or two tokens, so we can't walk a
> randomly partitioned cluster by token.
> solution: allow keys and tokens to be mixed. however, if one side is a
> token, promote the bounds to a dht.Range, instead of a dht.Bounds.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
