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
>> > 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