accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <>
Subject Re: Filters and ScannerBase.fetchColumn
Date Wed, 19 Mar 2014 23:15:55 GMT
On Wed, Mar 19, 2014 at 3:36 PM, Russ Weeks <>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

View raw message