hbase-dev mailing list archives

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

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

stack commented on HBASE-880:

Looking at this, regards RowOperation, don't you think the timestamp belong rather with the
specification of what we're to get or delete or update?  If we do this, it facilitates batching
a bunch of operations against the one row but each with its own timestamp specification (and
+1, the timestamp needs to be specifiable as a range with start and end for all Operations).

Is it true that we cannot do a mix of update/get/deletes on the one row all in the one operation
(as was possible with old BatchUpdate).  Looks like you'd do a get only, or an update only,
or a delete only; you might batch them true but they'd run in series rather than all as part
of the one row operation.  Is this the case?  (Its almost as though an Operation should 'have'
Gets, Deletes, and Updates)

IIRC, doing the below was problematic:

public RowResult getRow(RowGet) could be changed to return SortedMap<byte[], Cell>

Sorry, I don't remember the detail.

-1 on 'Rename RowUpdate to RowMutation.'  IMO, mutation is c++ speak whereas update is db

On constructors vs. setters, this is an age-old argument.  Lets have one or the other, not
both.  If lots of arguments, that would seem to favor setters though invoking all the setters
on a newly created object makes for ugly code -- and possibly half-initialized objects --
 and I dislike the fact that setters makes our objects mutable.

This stuff is hard.  I'm glad we've moved to diagramming.  Better for working out ideas.

Other things to consider:

+ Scanner API needs to align.
+ Batching needs to get diagrammed too so we're sure we have it covered.

> 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-patch.jpg, hbase-880-v1.patch, hbase-880-v2.patch, hbase_client_classes.png
> 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