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

Jean-Daniel Cryans commented on HBASE-880:
------------------------------------------

In my design, a RowOperation is to be subclassed into RowGet and BatchUpdate 
(or a better name would be RowMutation). The rest would be the same, the 
BatchUpdate still has a bunch of BatchOperation. When we will have batches of 
row updates, it would look like:

{code}
ArrayList<RowOperation> batch = new ArrayList<RowOperation>();
RowGet rowGet = new RowGet(row);
rowGet.addColumn("info:");
batch.add(rowGet)
//add some more gets in batch
RowResult[] results = htable.get(batch); // or maybe a SortedMap?

batch = new ArrayList<RowOperation>();
BatchUpdate update = new BatchUpdate(row);
//add some BatchOperation in it 
batch.add(update);
//add some more BatchUpdate  in batch
htable.commit(batch);
{code}

In Jim's design, a RowOperation aggregates many operations on a single row like 
BatchPut, BatchDelete, etc.

{code}
ArrayList<RowOperation> batch = new ArrayList<RowOperation>();
RowOperation op = new RowOperation(..., lock);
op.add(new BatchPut(...))
op.add(new BatchGet(...))
batch.add(op)
//add some more RowOperation in batch
RowResult[] results = htable.send(batch); // the results would come from the 
rows RowOperation that contained BatchGet/BatchGetRow
{code}



> Improve the current client API by creating new container classes
> ----------------------------------------------------------------
>
>                 Key: HBASE-880
>                 URL: https://issues.apache.org/jira/browse/HBASE-880
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.19.0
>
>
> The current API does not scale very well. For each new feature, we have to 
> add many methods to take care of all the overloads. Also, the need to batch 
> row operations (gets, inserts, deletes) implies that we have to manage some 
> "entities" like we are able to do with BatchUpdate but not with the other 
> operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another 
> feature-compatible one, other methods will be added in other issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to