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, 29 Apr 2009 16:13:30 GMT

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

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

@Holstad

Ok on the Get ... was just an idea.

I'd say lets drop TimeRange.

On Deletes, all is good to me except, seems like a 'delete' at now will have no effect, right?
 You have to know the timestamp to delete.  Maybe we should handle this case special -- go
find the latest and add the delete with that timestamp?

Other thoughts, we can't have HTable.get that takes a Get object because there already is
a get in HTable.  I think we need to start up a new class to hold all of the new stuff.  What
shall we call it?  HTable2?  We'll deprecate HTable in 0.20.0.



> 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
>             Fix For: 0.20.0
>
>         Attachments: 880.patch, 880proposal4plus-v2.patch, 880proposal4plus.patch, 880proposal5-v2.patch,
880proposal5-v2.png, 880proposal5.patch, 880proposal5.png, hbase-880-patch.jpg, hbase-880-proposal4.patch,
HBASE-880-proposal6-v2.txt, HBASE-880-proposal6-v3.txt, HBASE-880-proposal6-v4.txt, hbase-880-v1.patch,
hbase-880-v2.patch, HBASE-880_Design_Doc.pdf, HBASE-880_Design_Doc_v2.pdf, HBASE-880_Design_Doc_v3.pdf,
hbase_client_classes.png, NewCilentAPIProposoal4.gif, proposal2.jpg, proposed.jpg
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> 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