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 05:55:30 GMT

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

stack commented on HBASE-880:

More comments on  https://issues.apache.org/jira/secure/attachment/12406720/HBASE-880_Design_Doc_v3.pdf

In Get, do we need addFamily and addColumn?  Should it be just add?

I did an exercise where the verb used submitting Get, Delete, etc., was same for all but I
only ever got unsatisfactory results so lets use method names of get, put, delete, and scan.
 They each return different things anyways.  Might have to have batchPut, batchGet, and batchDelete,
too, because returns may vary if for example we are going to return timestamps of when the
Put happened.

Should we even have a Get?  Just always Scan even if one row only?  Just a thought.

Should we have a TimeRange?  Its only used in Get.  Just have a setTimestamp and then optional
range or depth to the Get? (setTimestampRange?)

Should deleteColumn in Delete be just delete?  Should we have a deleteFamily?  That'd leave
deleteColumns.  Do we need this?  Answer to below will help:

How do deletes work?  (I've seen the PDFs and its not plain to me).

If I do Delete.deleteColumn w/o a timestamp, whats this do?  Does it delete most recent cell
on the column only?  Or everything behind it in time? (This would be like a deleteColumns).
 If former, how does it work?   First it must find the most recent so it can find the timestamp?

If I pass a timestamp, what does it delete?  Only the cell at that timestamp if it exists?
 What if nothing exists there?  Nothing happens?

(Above is an old discussion rehashed)

> 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