[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923089#action_12923089 ]
Nate McCall commented on CASSANDRA-1600: ---------------------------------------- Sorry for chiming in late here, but I respectfully disagree with tjake and thobbs regarding the usefulness of this. I think there is enough misunderstanding around get_range_slices as is before adding this on top. get_indexed_slices is the only place where we apply conditions on the values of a column - I think that is different enough to warrant it's own function. This also sounds like a PITA when we factor in get_range_slices on SuperColumns and explaining that one to users. Fwiw- as for paging, I have personally dealt with 3 support issues in the past 5 days were people did not understand either the ramifications of empty byte[] on start and finish in the predicate's SliceRange and/or setting high counts for supercolumns. > 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 > Reporter: Stu Hood > Assignee: Jonathan Ellis > Fix For: 0.7.0 > > 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 > > > 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.