[
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:
------------------------------------
@Stack
+ 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.
