[
https://issues.apache.org/jira/browse/HBASE-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123876#comment-13123876
]
Ted Yu commented on HBASE-4102:
-------------------------------
{code}
+/**
+ * Testing of HRegion.incrementColumnValue
+ *
+ */
+public class TestAtomicOperation extends HBaseTestCase {
{code}
Javadoc should be updated for the new test.
For Mutation.java:
{code}
+ * @return the number of different families included in this put
+ */
+ public int numFamilies() {
{code}
I think put in javadoc should be mutation.
For Append.readFields():
{code}
+ if (version > APPEND_VERSION) {
+ throw new IOException("version not supported");
{code}
Value of version should be included in the exception.
For RegionCoprocessorHost.postAppend():
{code}
+ * @param appent Append object
{code}
there was a typo above.
For HRegion.append():
{code}
+ public Result append(Append append, Integer lockid, boolean writeToWAL)
+ throws IOException {
...
+ checkRow(row, "increment");
{code}
Second parameter above should be "append"
> 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.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
