Thanks for clearing that up for me. -Russ
On Wed, Mar 19, 2014 at 3:46 PM, Mike Drob <[email protected]> wrote: > > Yes, you are running into the same issue described in > https://issues.apache.org/jira/browse/ACCUMULO-1801 > > > On Wed, Mar 19, 2014 at 6:41 PM, John Vines <[email protected]> wrote: > >> Yes, column level filtering happens before any client iterators get a >> chance to touch the results. >> >> >> On Wed, Mar 19, 2014 at 6: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? >>> >>> Thanks, >>> -Russ >>> >> >> >
