Github user phrocker commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/247#discussion_r111038914
--- Diff:
core/src/main/java/org/apache/accumulo/core/iterators/OrIterator.java ---
@@ -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(), originalStartKey.getTimestamp());
+ // Construct the new range, preserving the other attributes on the
provided range.
+ currentRange = new Range(newKey,
originalRange.isStartKeyInclusive(), originalRange.getEndKey(),
originalRange.isEndKeyInclusive());
--- 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 [email protected] or file a JIRA ticket
with INFRA.
---
