[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011139#comment-13011139
]
Sylvain Lebresne commented on CASSANDRA-1600:
---------------------------------------------
Remarks/questions:
* In the thrift API, IndexClause should be deprecated too.
* I believe CASSANDRA-1034 should avoid the start_key and end_key in
RangeSliceCommand (since it preserves the keys in ranges) and thus in the
indexed iterator.
* I think there is a bug with the handling of end_key in getIndexedIterator
with wrapped ranges. If the requested range is wrapped, and a node range r is
before start_key but still in the [start_key, end_key] range (that is, r is
before end_key too), then we will query the index with a slice from start_key
to EMPTY_BB. But for that node that will never return anything, even though it
can very well have rows in the requested range. I actually think that
CASSANDRA-1034 would fix that too, since we'll use the range here instead of
[start_key, end_key] and getRestrictedRange will have taken care of this
problem for us.
* We should put EMPTY_FILTER_CLAUSE in FBUtilities and use it for
getRangeSliceUnfiltered too. And if we remove the {start|end}_key from
RangeSliceCommand, we could use the empty filter clause there too instead of
null and simplify the serializer.
* In getIndexedIterator, why not use the iterator on the returned column
family instead of allocating a new arrayQueue ?
* In RangeSliceVerbHandler, rowFilter is tested again null, but can't be.
Nice refactoring otherwise.
> Merge get_indexed_slices with get_range_slices
> ----------------------------------------------
>
> Key: CASSANDRA-1600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 0.8
>
> Attachments:
> 0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
> 0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt
>
>
> From a comment on 1157:
> {quote}
> IndexClause only has a start key for get_indexed_slices, but it would seem
> that the reasoning behind using 'KeyRange' for get_range_slices applies there
> as well, since if you know the range you care about in the primary index, you
> don't want to continue scanning until you exhaust 'count' (or the cluster).
> Since it would appear that get_indexed_slices would benefit from a KeyRange,
> why not smash get_(range|indexed)_slices together, and make IndexClause an
> optional field on KeyRange?
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
