cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
Date Fri, 25 Mar 2011 09:36:06 GMT


Sylvain Lebresne commented on CASSANDRA-1600:

    * 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:
>             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,
> 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:

View raw message