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

Jim Kellerman commented on HBASE-880:
-------------------------------------

A couple of comments:

ColumnCellMap and ColumnCellBoundsMap should be abstract so that someone 
doesn't instantiate one and try to have 
HBase figure out what the operation is.

A row lock cannot apply to all rows. If they did, when batching, you'd have to 
chase down every row in order to take a lock out
on it. row locks apply to a single row only. This means that either Get, Put 
and Delete must either overload the constructors
(-1 on that) or implement a setter which allows the client application to take 
out a lock on a row and then apply it to multiple
operations.

Could ColumnCellBoundsMap inherit from ColumnCellMap?

RowResult is not a RowOperation, but it is a HBaseMapWritable.

Otherwise, +1 once I got my head around what the UML was saying, I think that 
it will make for an elegant API.

> 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
>            Assignee: Jean-Daniel Cryans
>             Fix For: 0.19.0
>
>         Attachments: 880proposal4plus-v2.patch, 880proposal4plus.patch, 
> 880proposal5.patch, 880proposal5.png, hbase-880-patch.jpg, 
> hbase-880-proposal4.patch, hbase-880-v1.patch, hbase-880-v2.patch, 
> hbase_client_classes.png, NewCilentAPIProposoal4.gif, proposal2.jpg, 
> proposed.jpg
>
>
> 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