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, 29 Sep 2008 19:54:44 GMT

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

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

To clarify my previous comment (and correct a mistake):

The overall idea is to replace all gets and getRows with RowResult get(RowOperation). 
All updates, deleteAll and deleteFamily can be replaced with void commit(RowOperation)

- ColumnOperation is used for get and getRow. It has no value field so it cannot be used for
updates.
- ColumnOperation should have a single byte array for family:member, since family names are
printable. 
 - 'family:member' specifies a specific member of a family
 - 'family:' means the Cell in which the member name is null
 - 'family' (no delimiter) means all members in the family
 - a completely empty byte array means all members of all families

- ColumnMutations are a replacement for BatchOperation in which they subclass ColumnOperation
and add only the value.
 - an empty value specifies a delete just as BatchOperation does today



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


Mime
View raw message