[
https://issues.apache.org/jira/browse/CASSANDRA-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989913#comment-13989913
]
Benedict commented on CASSANDRA-7107:
-------------------------------------
Well, just to be sure:
* We translate a slice to the range \[lb..ub\) - i.e. lb is inclusive;
* We search in the range [0..lb) to translate the next slice - lb is exclusive
here
So I'm pretty sure it's fine - lb always gets returned in the first iterator,
and is never searched for building the following iterator, but is the exact
boundary at which we start our search.
> General minor tidying of CollationController path
> -------------------------------------------------
>
> Key: CASSANDRA-7107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7107
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 2.1 rc1
>
>
> There is a lot of unnecessary boiler plate when grabbing an iterator from an
> in-memory column family. This patch:
> * Removes FakeCellName
> * Avoids wrapping a non-OnDiskAtomIterator as an OnDiskAtomIterator except
> when the wrapping is useful
> * Removes ColumnSlice.NavigableSetIterator and creates a simpler more direct
> equivalent in ABTC
> * Does not construct a SliceIterator in either ABSC or ABTC if only one slice
> is requested (just returns that slice as an Iterator)
> * Does not construct multiple list indirections in ABSC when constructing a
> slice
> * Shares forward/reverse iterators in ABSC between slices and full-iteration
> * Avoids O(N) comparisons during collation of results into an ABSC, by using
> the knowledge that all columns are provided in insertion order from a merge
> iterator
--
This message was sent by Atlassian JIRA
(v6.2#6252)
