Alternatively you could strip the partition id off of the returned key before the data is accessed via your client API.
On Mon, Nov 12, 2012 at 7:29 AM, Anthony Fox <[email protected]> wrote: > 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 >> > >
