accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Unexpected aliasing from RFile getTopValue()
Date Wed, 15 Apr 2015 01:43:26 GMT
Well, it depends on the behavior of the iterator beneath it. Most iterators
would probably not want to copy, for performance reasons, but an iterator
could choose to break that convention (or may need to). It is kind of
unintuitive that a developer would need to understand the behavior of the
iterator beneath it, so a best practice is probably to just copy inside
your iterator, if you need a copy.

I know we've discussed trying to revamp the iterator API before, so if you
think there's something we could do to make this a bit more intuitive,
that'd be very welcome and appreciated.

On Tue, Apr 14, 2015 at 8:57 PM Dylan Hutchison <dhutchis@mit.edu> wrote:

> While debugging a custom iterator today to find the source of a logical
> error, I discovered something an iterator developer may not expect.  The
> getTopValue() of RFile returns a reference to the RFile's internal Value
> private variable.  The private variable is modified inside RFile via
>
>
> val.readFields(currBlock);
>
>
> which means that if an iterator stores the reference from getTopValue(),
> that is, without copying the Value to a new Object, then the value will be
> updated in the iterator when the RFile's next() method is called.
>
> Here is an example snippet to demonstrate:
>
> Value v1 = source.getTopValue();
>
> source.next();                                   // v1 is modified!
>
>
> The following code would not have a problem:
>
> Value v1 = new Value(source.getTopValue());
>
> source.next();
>
>
> I bet this is done for performance reasons.  Is this expected?
>
> Regards, Dylan
>

Mime
View raw message