[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-1600:
----------------------------------------
Attachment: (was:
0003-Allow-get_range_slices-to-apply-filter-to-a-sequenti-v3.patch)
> 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: Sylvain Lebresne
> Fix For: 1.1
>
> Attachments:
> 0001-Add-optional-FilterClause-to-KeyRange-and-support-do-v2.patch,
> 0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
> 0001-Add-optional-FilterClause-to-KeyRange-v3.patch,
> 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,
> 0002-thrift-generated-code-changes-v3.patch,
> 0003-Allow-get_range_slices-to-apply-filter-to-a-sequenti-v3.patch,
> 0004-Update-cql-to-not-use-deprecated-index-scan-v3.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
