hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Kellerman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Mon, 01 Dec 2008 23:10:44 GMT

    [ 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

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.

View raw message