accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From phrocker <>
Subject [GitHub] accumulo pull request #247: ACCUMULO-3208 Integration test for the OrIterato...
Date Tue, 11 Apr 2017 23:58:35 GMT
Github user phrocker commented on a diff in the pull request:
    --- Diff: core/src/main/java/org/apache/accumulo/core/iterators/ ---
    @@ -80,59 +128,103 @@ public int compareTo(TermSource o) {
           // sorted after they have been determined to be valid.
           return this.iter.getTopKey().compareColumnQualifier(o.iter.getTopKey().getColumnQualifier());
    +    /**
    +     * Converts the given {@code Range} into the correct {@code Range} for this TermSource
(per this expected table structure) and then seeks this TermSource's
    +     * SKVI.
    +     */
    +    public void seek(Range originalRange) throws IOException {
    +      // the infinite start key is equivalent to a null startKey on the Range.
    +      if (!originalRange.isInfiniteStartKey()) {
    +        Key originalStartKey = originalRange.getStartKey();
    +        // Pivot the provided range into the range for this term
    +        Key newKey = new Key(originalStartKey.getRow(), term, originalStartKey.getColumnQualifier(),
    +        // Construct the new range, preserving the other attributes on the provided range.
    +        currentRange = new Range(newKey, originalRange.isStartKeyInclusive(), originalRange.getEndKey(),
    --- End diff --
    Are you sure you want to trust the start key  inclusivity flag if you are setting term
in the new key above?  Seems like if you're adjusting the range you want to make your key
inclusive. Am I wrong in my logic?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message