[jira] [Commented] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter

["David Alves (JIRA)" <ji...@apache.org>]

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

David Alves commented on CASSANDRA-3885:
----------------------------------------

Hi Vijay

 Sorry for the delay also, somehow I didn't get notified that the issue was updated/commented.
 1) - With regard to SliceRange you're right, I just wanted to get some feedback before changing thrift stuff
 2) - We can definitely avoid that, maybe make IndexedSliceReader receive the ranges as an array?
 3) - Hadn't thought about that... maybe we could have a internal (within org.apache.cassandra.db) version and transform?
 4) - Cacheing the results is not about query validation, at least I can't see how better query validation would discard the necessity of cacheing to avoid re-reads. There is always a scenario where cacheing the results avoids re-reads (when we're sure that the next reversed range will need them), the thing is that right now we're cacheing without knowing that they wether they will be necessary (vs making sure the previous range will need them). In any case the maximum that gets cached is an index range of records per query so that might not be a terrible issue. What do you think?
                
> Support multiple ranges in SliceQueryFilter
> -------------------------------------------
>
>                 Key: CASSANDRA-3885
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3885
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>             Fix For: 1.2
>
>         Attachments: CASSANDRA-3885.patch
>
>
> This is logically a subtask of CASSANDRA-2710, but Jira doesn't allow sub-sub-tasks.
> We need to support multiple ranges in a SliceQueryFilter, and we want querying them to be efficient, i.e., one pass through the row to get all of the ranges, rather than one pass per range.
> Supercolumns are irrelevant since the goal is to replace them anyway.  Ignore supercolumn-related code or rip it out, whichever is easier.
> This is ONLY dealing with the storage engine part, not the StorageProxy and Command intra-node messages or the Thrift or CQL client APIs.  Thus, a unit test should be added to ColumnFamilyStoreTest to demonstrate that it works.

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