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 Tue, 02 Dec 2008 16:50:44 GMT

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

Jim Kellerman commented on HBASE-880:

Thinking on this more (which I should have done before making the
previous comment), it would be cleaner to remove the Iterable and multi-
value multi-timestamp stuff from Cell (which was done so that the
multi-version stuff could work within the confines of the current API).

Instead, my suggestion would be to make RowResult a Map<byte[], Cell[]>
This means that a RowResult is not a HBaseMapWritable.

Also Get and Delete should HaveA CellBoundsMap instead of inheriting
the HaveA relation from ColumnCellBoundsMap.

Since only Get returns a RowResult, how about having two methods instead
of running them all through commit:

public RowResult get(Get)
public void commit(UpdateOperation)

where an update operation is either a Put or a Delete?

> 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: 880.patch, 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