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

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

>From IRC with Doğacan:
{code}
[13:10] <dogacan>       st^ack: maybe I am just being thick, but I don't 
understand why exposing Specification or Scope is useful than just doing 
get.setTimestamp(col, timestamp) ?
[13:22] <st^ack>        I thought point of latest proposal was extraction of 
the Specification/Scope object.
[13:23] <st^ack>        When you add the getters/setters back to Get and Delete 
(but not to Put because it doesn't have Specification/Scope), then the 
advantage of the last proposal goes away?
[13:25] <st^ack>        If the setting is done against Specification, then 
Get/Delete/Put can be immutable and all treated the same.
[13:51] <dogacan>       hmm
[13:51] <dogacan>       I see
[13:52] <dogacan>       i forgot about trying to make get/delete/put as similar 
as possible :)
[13:52] <dogacan>       let me think about it, thanks
{code}

> 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-proposal4.patch, 
> hbase-880-v1.patch, hbase-880-v2.patch, hbase_client_classes.png, 
> NewCilentAPIProposoal4.gif, 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.

Reply via email to