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

Jonathan Gray commented on HBASE-4102:
--------------------------------------

This is really nice Lars.  I'd love to see integration with RWCC and to somehow 
unify the code with Increment.  But I'm okay with committing this and filing a 
follow-up JIRA.

I'm also going to backport this into my local 92 branch but I think it should 
only be committed to trunk.  Let's put all the polish on before putting it in 
an official release.

Nice work!
                
> atomicAppend: A put that appends to the latest version of a cell; i.e. reads 
> current value then adds the bytes offered by the client to the tail and 
> writes out a new entry
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-4102
>                 URL: https://issues.apache.org/jira/browse/HBASE-4102
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: stack
>            Assignee: Lars Hofhansl
>         Attachments: 4102-v1.txt, 4102.txt
>
>
> Its come up a few times that clients want to add to an existing cell rather 
> than make a new cell each time.  At our place, the frontend keeps a list of 
> urls a user has visited -- their md5s -- and updates it as user progresses.  
> Rather than read, modify client-side, then write new value back to hbase, it 
> would be sweet if could do it all in one operation in hbase server.  TSDB 
> aims to be space efficient.  Rather than pay the cost of the KV wrapper per 
> metric, it would rather have a KV for an interval an in this KV have a value 
> that is all the metrics for the period.
> It could be done as a coprocessor but this feels more like a fundamental 
> feature.
> BenoƮt suggests that atomicAppend take a flag to indicate whether or not the 
> client wants to see the resulting cell; often a client won't want to see the 
> result and in this case, why pay the price formulating and delivering a 
> response that client just drops.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to