You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/10/11 04:42:10 UTC
[jira] Created: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
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
Priority: Critical
Fix For: 0.7.0
>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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920702#action_12920702 ]
T Jake Luciani commented on CASSANDRA-1600:
-------------------------------------------
+1 I agree this should be done in one call.
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Affects Version/s: 0.7 beta 1
Fix Version/s: (was: 0.7.0)
0.8
Given the lack of consensus I don't think forcing this through just before rc1 is the right thing to do. Deferring to 0.8.
> 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
> Affects Versions: 0.7 beta 1
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 0.8
>
> 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, AbstractScanIterator.java
>
>
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921230#action_12921230 ]
Stu Hood commented on CASSANDRA-1600:
-------------------------------------
> applies row_filter during a row scan
I'm willing to say that this should be "considered harmful". Without a toggle to disable the RPC_TIMEOUT, we'd be setting people up for their unbounded scans to succeed in testing, and then cause cascading failures in production by going into retry loops that scan (70 MB * 10s) of data before timing out.
Indexed scans are safe, in that the worst case is that you don't match anything in your index, and you have to get empty results from every node in your cluster. Empty results are cheap.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921441#action_12921441 ]
Stu Hood commented on CASSANDRA-1600:
-------------------------------------
> You seem to be arguing that there exists a body of users who somehow know to avoid misusing get_range_slices outside Hadoop now, but won't after this change
Yes, I'm arguing that. People know how to perform paging.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: 0009-rename-Index-Filter.txt
0008-allow-applying-row-filtering-to-sequential-scan.txt
0007-Respect-end_key-for-filtered-queries.txt
0006-Remove-start_key-from-IndexClause-for-the-start_key-in.txt
0005-Update-system-tests-to-use-get_range_slices.txt
0004-Remove-get_indexed_slices-method.txt
0003-Execute-RangeSliceCommands-using-scan-when-an-IndexCla.txt
0002-Drop-the-IndexClause.count-parameter.txt
0001-Add-optional-IndexClause-to-KeyRange-and-serialize-wit.txt
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921079#action_12921079 ]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
am i missing something? i'm not seeing where this either respects the end_key during an index scan, or applies row_filter during a row scan, both of which are implied by the api change. if we're not going to merge semantics then they really should remain separate calls.
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921416#action_12921416 ]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
You seem to be arguing that there exists a body of users who somehow know to avoid misusing get_range_slices outside Hadoop now, but won't after this change. I don't see that. Is there a change in degree? Yes. But in kind? No.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Tyler L. Hobbs (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Reopened: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood reopened CASSANDRA-1600:
---------------------------------
> 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
> Priority: Critical
> 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.
[jira] Issue Comment Edited: (CASSANDRA-1600) Merge
get_indexed_slices with get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922724#action_12922724 ]
Jonathan Ellis edited comment on CASSANDRA-1600 at 10/19/10 5:25 PM:
---------------------------------------------------------------------
rebased and added ability to filter rows in sequential scan (0008). also renames Index* to Filter* in Thrift and Avro (0009).
was (Author: jbellis):
rebased and added ability to filter rows in sequential scan. also renames Index* to Filter* in Thrift and Avro.
> 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.
[jira] Issue Comment Edited: (CASSANDRA-1600) Merge
get_indexed_slices with get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921230#action_12921230 ]
Stu Hood edited comment on CASSANDRA-1600 at 10/15/10 1:14 AM:
---------------------------------------------------------------
> applies row_filter during a row scan
I'm willing to say that this should be "considered harmful". Without a toggle to disable the RPC_TIMEOUT, we'd be setting people up for their unbounded scans to succeed in testing, and then cause cascading failures in production by going into retry loops that scan (70 MB * 10s) of data before timing out.
Indexed scans are safe, in that the worst case is that you don't match anything in your index, and you have to get empty results from every node in your cluster. Empty results are cheap.
EDIT: And yes, I realize that our current scheme for boolean operations between clauses ends up reverting to a scan, but that is fixable via a merge join of the indexes (or 1472), which would preserve the safety I mention.
was (Author: stuhood):
> applies row_filter during a row scan
I'm willing to say that this should be "considered harmful". Without a toggle to disable the RPC_TIMEOUT, we'd be setting people up for their unbounded scans to succeed in testing, and then cause cascading failures in production by going into retry loops that scan (70 MB * 10s) of data before timing out.
Indexed scans are safe, in that the worst case is that you don't match anything in your index, and you have to get empty results from every node in your cluster. Empty results are cheap.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: 0006-Remove-start_key-from-IndexClause-for-the-start_key-.patch
0005-Update-system-tests-to-use-get_range_slices.patch
0004-Remove-get_indexed_slices-method.patch
Rebased for trunk.
> 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.
[jira] Resolved: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-1600.
---------------------------------------
Resolution: Invalid
the semantics of "give me all the rows with column value X" and "give me all the rows between Y and Z" are different enough that smashing them together feels like the wrong thing to do. Nor is stop_key on index scans something we want to optimize for.
> 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
> Priority: Critical
> Fix For: 0.7.0
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
> Attachments: 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Tyler L. Hobbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923110#action_12923110 ]
Tyler L. Hobbs commented on CASSANDRA-1600:
-------------------------------------------
If we aren't supporting secondary indexes for super column families in the near future, then explaining how things work with SuperColumns is as simple as saying "you can't use a filter on a super column family" and throwing an IRE.
I do think the clients should do a better job of supporting paging given the number of questions on it, though.
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Priority: Major (was: Critical)
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: AbstractScanIterator.java
attaching AbstractScanIterator.java that was missing from patchset. Applies to r1024332
> 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, AbstractScanIterator.java
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0005-Update-system-tests-to-use-get_range_slices.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0005-Update-system-tests-to-use-get_range_slices.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0006-Remove-start_key-from-IndexClause-for-the-start_key-.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0006-Remove-start_key-from-IndexClause-for-the-start_key-.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
> Attachments: 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921352#action_12921352 ]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
> we'd be setting people up for their unbounded scans to succeed in testing, and then cause cascading failures in production by going into retry loops
we already have this problem with the existing get_range_slices and excessively large count values. it turns out that allowing people to do more powerful/efficient things is the right choice even when it is potentially dangerous.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0004-Remove-get_indexed_slices-method.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: 0007-Respect-end_key-for-filtered-queries.patch
Adding 0007 to respect 'end_key' for filtered get_range_slices calls.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922724#action_12922724 ]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
rebased and added ability to filter rows in sequential scan. also renames Index* to Filter* in Thrift and Avro.
> 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.
[jira] Issue Comment Edited: (CASSANDRA-1600) Merge
get_indexed_slices with get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921390#action_12921390 ]
Stu Hood edited comment on CASSANDRA-1600 at 10/15/10 10:47 AM:
----------------------------------------------------------------
> we already have this problem with the existing get_range_slices and excessively large count values.
In that case, the user is explicitly saying, give me a lot of stuff. The fix (in production) would be a one line code change, not the emergency addition of an index.
> it turns out that allowing people to do more powerful/efficient things is the right choice even when it is potentially dangerous
I disagree. http://jsomers.net/blog/it-turns-out
If we're talking about the specific case of adhoc analytics queries, then we should discuss them independently, because they really are a whole different beast. For instance, if the idea here is that you would perform filtering in Cassandra rather than in the Hadoop process, you are not saving anything but ser/de time, since the recommended way to deploy Hadoop is directly on localhost.
was (Author: stuhood):
> we already have this problem with the existing get_range_slices and excessively large count values.
In the case, the user is explicitly saying, give me a lot of stuff. The fix (in production) would be a one line code change, not the emergency addition of an index.
> it turns out that allowing people to do more powerful/efficient things is the right choice even when it is potentially dangerous
I disagree. http://jsomers.net/blog/it-turns-out
If we're talking about the specific case of adhoc analytics queries, then we should discuss them independently, because they really are a whole different beast. For instance, if the idea here is that you would perform filtering in Cassandra rather than in the Hadoop process, you are not saving anything but ser/de time, since the recommended way to deploy Hadoop is directly on localhost.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "T Jake Luciani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922763#action_12922763 ]
T Jake Luciani commented on CASSANDRA-1600:
-------------------------------------------
+1
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.patch
0002-Drop-the-IndexClause.count-parameter.patch
0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.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: 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920708#action_12920708 ]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
Sounds like the ayes have it. Stu, if you can rebase we'll get this in.
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921390#action_12921390 ]
Stu Hood commented on CASSANDRA-1600:
-------------------------------------
> we already have this problem with the existing get_range_slices and excessively large count values.
In the case, the user is explicitly saying, give me a lot of stuff. The fix (in production) would be a one line code change, not the emergency addition of an index.
> it turns out that allowing people to do more powerful/efficient things is the right choice even when it is potentially dangerous
I disagree. http://jsomers.net/blog/it-turns-out
If we're talking about the specific case of adhoc analytics queries, then we should discuss them independently, because they really are a whole different beast. For instance, if the idea here is that you would perform filtering in Cassandra rather than in the Hadoop process, you are not saving anything but ser/de time, since the recommended way to deploy Hadoop is directly on localhost.
> 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0004-Remove-get_indexed_slices-method.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Assignee: (was: Jonathan Ellis)
> 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
> Affects Versions: 0.7 beta 1
> Reporter: Stu Hood
> Fix For: 0.8
>
> 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, AbstractScanIterator.java
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: (was: 0002-Drop-the-IndexClause.count-parameter.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: 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0007-Respect-end_key-for-filtered-queries.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
>
> 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.
[jira] Assigned: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-1600:
-----------------------------------------
Assignee: Jonathan Ellis
> 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Nate McCall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1600:
--------------------------------------
Attachment: (was: 0002-Drop-the-IndexClause.count-parameter.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: Improvement
> Components: API
> Reporter: Stu Hood
> Fix For: 0.7.0
>
> Attachments: 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, 0007-Respect-end_key-for-filtered-queries.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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.patch
0002-Drop-the-IndexClause.count-parameter.patch
0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.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: Improvement
> Components: API
> Reporter: Stu Hood
> Priority: Critical
> 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919907#action_12919907 ]
Stu Hood commented on CASSANDRA-1600:
-------------------------------------
> "give me all the rows between Y and Z"
The semantics of get_indexed_slices is still "give me all the rows between Y and Z", with the one addition that it applies a filter. I'm going to make a patch that does this: if it is not ugly, then I'm going to reopen this issue.
> 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
> Priority: Critical
> Fix For: 0.7.0
>
>
> 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.
[jira] Updated: (CASSANDRA-1600) Merge get_indexed_slices with
get_range_slices
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1600:
--------------------------------
Attachment: 0006-Remove-start_key-from-IndexClause-for-the-start_key-.patch
0005-Update-system-tests-to-use-get_range_slices.patch
0004-Remove-get_indexed_slices-method.patch
Patchset to merge get_range_slices and get_indexed_slices: drops ~200 hand written lines and ~1400 thrift generated lines.
> 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
> Priority: Critical
> 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.