Github user denine99 commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/33#discussion_r29158839
--- Diff: docs/src/main/asciidoc/chapters/iterator_design.txt ---
@@ -145,8 +146,16 @@ alter the internal state of the Iterator.
These methods simply return the current Key-Value pair for this iterator.
If `hasTop` returns true,
both of these methods should return non-null objects. If `hasTop` returns
false, it is undefined
-what these methods should return. Multiple calls to these methods should
not alter the state
-of the Iterator like `hasTop`.
+what these methods should return. Like `hasTop`, multiple calls to these
methods should not alter
+the state of the Iterator.
+
+When saving a Key or Value from a source iterator's `getTopKey` or
`getTopValue` methods
+for use after calling `next` on the source iterator (e.g., when cacheing
keys or values
+from the source iterator), it is important to copy the Key or Value into a
new object
+because the source iterator may reuse the Key or Value objects for
performance reasons.
--- End diff --
Hi Josh,
Take a look at the [Accumulo mail list posting
here](https://mail-archives.apache.org/mod_mbox/accumulo-user/201504.mbox/%3C552E8941.8080908%40gmail.com%3E).
This outlines my experience with aliasing from a Value in an RFile. The
consensus is that aliasing is a good thing by default for performance reasons
(less copying than if the base iterator allocated new memory every read).
Collapsing a bunch of columns into a single K/V is safe if the intermediary
K/Vs are copied each time.
---
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.
---
