On Wed, Mar 19, 2014 at 3:36 PM, Russ Weeks <[email protected]>wrote:
> Sorry for the flood of e-mails... I'm not trying to spam the list, I'm > just getting deeper into accumulo, and loving it, and I'm kind of stumped > by it at the same time. > > Is it true that if a scanner restricts the column families/qualifiers to > be returned, that these columns are not visible to any iterators? ie. that > this restriction is applied at a higher "priority" than any of the > iterators? > > I have some rows that look like this: > > 000200001cdaac30 meta:size [] 656 > 000200001cdaac30 meta:source [] data2 > 000200001cfaac30 meta:filename [] doc04484522 > 000200001cfaac30 meta:size [] 565 > 000200001cfaac30 meta:source [] data2 > 000200001dcaac30 meta:filename [] doc03342958 > > I have a couple of RowFilters chained together to filter based on source > and filename. If I just run "scan --columns meta:size" I get no results. I > have to specify "scan --columns meta:size,meta:source,meta:filename" to get > any results, which implies that I need to know beforehand which columns are > required for any active iterators. > > Is this expected behaviour? > Which columns an iterator should return are specified in the seek method. The decisionIterator that the RowFilter uses to determine if a row should be accepted could be seeked to different columns than the RowFilter itself is provided. However, the default implementation of RowFilter does not do this. There might be a fairly straightforward change that could be made to RowFilter that would allow its subclasses to customize the columns passed to the decisionIterator. > > Thanks, > -Russ >
