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

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

So you are saying if we do a delete at now, and there is no entry in the 
memcache, we just don't add it?

Our change in how delete works where we move away from first getting all the 
entries the delete covers so we can write individual deletes per existing cell 
will require a migration of all data.  I'm not opposed to that.  Just noting 
that it will be required (The way we do deletes currently just doesn't scale -- 
has to change so I'm w/ you Holstad when you say "I don't really like to go 
look for things to delete...")

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

Reply via email to