You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremy Hanna (JIRA)" <ji...@apache.org> on 2011/01/01 20:51:45 UTC

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976440#action_12976440 ] 

Jeremy Hanna commented on CASSANDRA-1600:
-----------------------------------------

As Jonathan mentioned in IRC, it seems like map/reducing over indexes will be much simpler if get_indexed_slices and get_range_slices were the same call.

Also, there have been several bugs in the get_range_slices over the last 8 months.  If we duplicate any code there, I worry that we're multiplying our problems in the future.  So even if we decide on separate functions, code reuse in there is a good idea for that reason.

> Merge get_indexed_slices with get_range_slices
> ----------------------------------------------
>
>                 Key: CASSANDRA-1600
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 0.7 beta 1
>            Reporter: Stu Hood
>             Fix For: 0.8
>
>         Attachments: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-wit.txt, 0002-Drop-the-IndexClause.count-parameter.txt, 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexCla.txt, 0004-Remove-get_indexed_slices-method.txt, 0005-Update-system-tests-to-use-get_range_slices.txt, 0006-Remove-start_key-from-IndexClause-for-the-start_key-in.txt, 0007-Respect-end_key-for-filtered-queries.txt, 0008-allow-applying-row-filtering-to-sequential-scan.txt, 0009-rename-Index-Filter.txt, AbstractScanIterator.java
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.