[
https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126137#comment-13126137
]
Lars Hofhansl commented on HBASE-4102:
--------------------------------------
At closer look Append and Put are subtly different when it comes to version
handling (so they probably will still need to have separate implementations of
readFields and write (which is not the bulk of the class, as I moved the other
common code into Mutation and OperationWithAttributes as part of HBASE-4347).
There're still opportunities to unify some common code between Put and
Increment (and now Append), and as you say that is probably for another jira.
Yet another question is the use of Attributes to add flags to Operations
(get/scan/put/increment/append). It's nice because it allows adding flags
without changing RPC versions. On the other hand it relies on a user never
using the attribute that we're using for a flag. I am wondering whether should
eat an incompatibility once and add "system attributes" (or something) that are
independent from the user attributes. Then we can add flags to these operation
without RPC changes and with interfering with user attributes.
If we do this, it might be good to do that with 0.92.
I'd also like to understand what RWCC means for the upsert store operation.
That all said... I fixed the copyright notice and added more comments, and will
check this into trunk soon.
> 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
> Fix For: 0.94.0
>
> 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
