[jira] [Commented] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ 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