cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler L. Hobbs (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
Date Wed, 13 Oct 2010 17:57:36 GMT

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

Tyler L. Hobbs commented on CASSANDRA-1600:
-------------------------------------------

>From an API perspective, I think it does make sense to merge the two.

They are fundamentally the same operation.  As Stu says, get_indexed_slices() only adds a
filter to get_range_slices().  This is close enough (and the filter is self-contained enough)
that I don't think a separate function is needed.  I think the merged version would probably
be easier for a new developer to grok, as well.

I can't comment on the backend parts of this.  If those are troublesome enough to keep the
two separate, then it might make sense to do this at the client level.

> 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
>             Fix For: 0.7.0
>
>         Attachments: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.patch,
0002-Drop-the-IndexClause.count-parameter.patch, 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.patch,
0004-Remove-get_indexed_slices-method.patch, 0005-Update-system-tests-to-use-get_range_slices.patch,
0006-Remove-start_key-from-IndexClause-for-the-start_key-.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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message