accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Billie Rinaldi (Commented) (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-403) Create general row selection iterator
Date Sat, 10 Mar 2012 17:12:58 GMT


Billie Rinaldi commented on ACCUMULO-403:

It seems like the decisionIterator shouldn't be restricted to the same column families that
are returned by the RowFilter.  Is the suggested usage that the subclass reseek in the acceptRow
method if it wants different columns?
> Create general row selection iterator
> -------------------------------------
>                 Key: ACCUMULO-403
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client, tserver
>            Reporter: Keith Turner
>            Assignee: Keith Turner
>             Fix For: 1.4.0
> The WholeRowIterator support filtering rows that meet a certain criteria.  However it
reads the entire row into memory.  It is possible to efficiently select rows w/o reading them
into memory by using two iterators.  One iterator for selection, one for reading.  When its
determined that a row is not needed using the selection iterator, then seek the read iterator
over the row.  
> This pattern could be made into an easy to use iterator that users extend.  The iterator
could have an abstract method that user implement to decide if they want to select or filter
a row.  Could look something like the following.
> {noformat}
> class RowSelectionIterator extends WrappingIterator {
>    public abstract boolean selectRow(SortedKeyValueIterator row);
> }
> {noformat}
> Below is a simple example of a row selection iterator that returns rows that have the
columns foo and bar.
> {noformat}
> class FooBarRowSelector extends  RowSelectionIterator {
>    public boolean selectRow(SortedKeyValueIterator row){
>       Text row = row.getTopKey().getRow();
>       //seek instead of scanning, this more efficient for large rows w/ lots of columns...

>       //if the row only has a few columns scanning is probably faster... also seeking
>       //columns in sorted order is more efficient.
>, 'bar');
>       boolean sawBar = row.hasTop();
>       if(!sawBar)
>         return false;
>, 'foo'));
>       boolean sawFoo = row.hasTop();
>       return sawFoo;
>    }
> }
> {noformat}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message