[ 
https://issues.apache.org/jira/browse/HBASE-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087111#comment-13087111
 ] 

stack commented on HBASE-4223:
------------------------------

This patch is very interesting.  It seems to be adding new 'functionality' to 
coprocessors.  Sweet.

nit: lines lengths in the rest of the code base are generally < 80 chars and 
tabs are two spaces.

This is a sort of cache Nichole?

{code}
this.kvs = finalResults.toArray(new KeyValue[results.size()]);
{code}

... so you'd have to do a getList before you'd get anything out of a getMap?  
Is this interdependency doc'd anywhere?  (Similar with getNoVersionMap and 
dependency on getList -- isEmpty too)

I was wondering about the getMap running serverside?  Maybe just do this in 
client?  We're going to have to shuttle the payload across regardless.

Yeah, paging though I'd suggest the paging be size based rather than element 
count.

I don't know much about how CPs work but is there means of keeping state 
between client and server (with resources let go if client goes away?)





> Support the ability to return a set of rows using Coprocessors
> --------------------------------------------------------------
>
>                 Key: HBASE-4223
>                 URL: https://issues.apache.org/jira/browse/HBASE-4223
>             Project: HBase
>          Issue Type: Improvement
>          Components: coprocessors
>    Affects Versions: 0.92.0
>            Reporter: Nichole Treadway
>            Priority: Minor
>         Attachments: HBASE-4223.patch
>
>
> Currently HBase supports returning the results of aggregation operations 
> using coprocessors with the AggregationClient. It would be useful to include 
> a client and implementation which would return a set of rows which match a 
> certain criteria using coprocessors as well. We have a use case in our 
> business process for this. 
> We have an initial implementation of this, which I've attached. The only 
> limitation that we've found is that it cannot be used to return very large 
> sets of rows. If the result set is very large, it would probably require some 
> sort of pagination.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to