hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Holstad (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Wed, 29 Apr 2009 07:33:30 GMT

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

Erik Holstad commented on HBASE-880:

+ I think we should have a Get, haven't looked too closely at the scanner code, but I assume
that there is a scanner setup cost that we don't want to pay for random reads.

+ When it comes to TimeRange I don't really care if we have it or not, we might as well have
an extra time in the Get Object. 

+ The way I look at deletes is from the starting point that we added these delete types, a
way of making deletes as easy as possible. And the reason we have to types is so we can have
as much information in one single KeyValue as possible. And since they are a part of a KeyValue
it leaves us with one timestamp for each type. So the way we have reasoned about it is that
all the deletes except delete removes all the values that match after the specified timestamp,
if no timestamp is sepcified that is set to now. For the simple delete you specify the timestamp
you want to delete and it apllies to that timestamp only.
I think we should keep all the delete types that we currently have since it makes it easy
for the client to delete things, even though deleteRow, which turns into a deleteFamily on
the server side, and deleteFamily itself needs to be taken care in a special way, since they
don't sort like the other entries. 

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

View raw message