hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Wed, 10 Sep 2008 18:35:44 GMT

    [ 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:

ArrayList<RowOperation> batch = new ArrayList<RowOperation>();
RowGet rowGet = new RowGet(row);
//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 
//add some more BatchUpdate  in batch

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

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

> 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.

View raw message