Yes, we can definitely work around it as you suggest, though the transformed key/value fit the semantics of the domain a bit better. Since we're using the intersecting iterator, I'm trying to hide the random partition row id from a consumer of this API.
On Mon, Nov 12, 2012 at 9:44 AM, Josh Elser <[email protected]> wrote: > The last time I looked at that code, every resulting key was silently > removed by the TabletServerBatchReader(Iterator). > > That being said, it was previously impossible to turn off that final range > check as you asked. I'd have to double check the code again, though. > > Would it be possible in your application to place your aggregated > information in some serialized representation inside of the Value and > preserve the original Key? > > On Monday, November 12, 2012, Anthony Fox <[email protected]> wrote: > > I am trying to limit scans to a subset of stored rows by setting ranges. > The scan has an iterator that does some aggregation and transformation of > the result. Specifically, it changes the rowid to be more meaningful but > at the same time outside of the specified range. By instrumenting the > iterator with debug messages, I can verify that the expected rows are > actually processed. But it appears that the range filter is applied to the > result of the transformation that the iterator is making. Basically, I'm > trying to get something like a sql projection: > > select myTransformation(id) from myTable where id between (start and > end); > > Is it possible to set the precedence of the range filter and the > iterator that I am using so that I can do this transformation without > filtering all the results? > > > > Thanks, > > Anthony >
