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 Wed, 01 Oct 2008 18:15:44 GMT

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

stack commented on HBASE-880:
-----------------------------

Big improvement I'd say:

I suppose commit should be named 'update' in HTable to go with names of the new classes?

RowUpdate should be called UpdateOperation to match GetOperation?

Then, I'd suggest that 'DeleteOperation' become 'Delete' and 'UpdateOperation' become 'Update'
since they inherit form 'AbstractUpdate' rather than from 'RowOperation'.  Will keep confusion
down.

Would suggest removing all of the column/value methods from RowOperation derivatives (Should
there be a Get to go with the Delete and Update above)?

Unrelated, isTableEnabled should be in HBaseAdmin rather than here in HTable?

These diagrams have set me thinking we can make things even more straight-forward if we break
out a new class in which we describe the area  -- or 'sweep'/'reach'/'scope' -- an operation
is to effect.  Let me post a little drawing of what I'm thinking.

> 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,
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.


Mime
View raw message