[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018051#comment-13018051 ]
Jeremy Hanna commented on CASSANDRA-1600: ----------------------------------------- Is this going to get in by the April 11th code freeze? > 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-do-v2.patch, > 0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt, > 0002-allow-get_range_slices-to-apply-filter-to-a-sequenti-v2.patch, > 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