[
https://issues.apache.org/jira/browse/HADOOP-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565149#action_12565149
]
Hadoop QA commented on HADOOP-2611:
-----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12374626/2611-v3.patch
against trunk revision 616796.
@author +1. The patch does not contain any @author tags.
javadoc -1. The javadoc tool appears to have generated 1 warning messages.
javac +1. The applied patch does not generate any new javac compiler
warnings.
release audit +1. The applied patch does not generate any new release
audit warnings.
findbugs +1. The patch does not introduce any new Findbugs warnings.
core tests +1. The patch passed core unit tests.
contrib tests -1. The patch failed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/1731/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/1731/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/1731/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/1731/console
This message is automatically generated.
> [hbase] Make BatchUpdate public in the API
> ------------------------------------------
>
> Key: HADOOP-2611
> URL: https://issues.apache.org/jira/browse/HADOOP-2611
> Project: Hadoop Core
> Issue Type: New Feature
> Components: contrib/hbase
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.17.0
>
> Attachments: 2611-v2.patch, 2611-v3.patch, 2611.patch
>
>
> Today, when you want to interact with a row in HBase, you start an update,
> make changes, and then commit the lock. This is fine for very simple
> applications. However, when you try to do things like support table
> operations as part of a MapReduce job, it becomes more difficult to support.
> I propose that we create a new class, RowMutation (a la the Bigtable paper),
> which encapsulates a group of actions on a row, and make this available to
> API consumers. It might look something like:
> {code}
> RowMutation r = table.getMutation(row_key);
> r.setTimestamp(1111);
> r.put(new Text("colfam1:name", value));
> r.delete(new Text("colfam2:deleted"));
> table.commit(r);
> {code}
> This syntax would supercede the existing startUpdate/commit format, which
> could be deprecated and mapped to a RowMutation behind the scenes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
