cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nate McCall (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
Date Wed, 20 Oct 2010 18:52:24 GMT


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:
>             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.

View raw message