[ 
https://issues.apache.org/jira/browse/HADOOP-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564261#action_12564261
 ] 

Bryan Duxbury commented on HADOOP-2611:
---------------------------------------

After talking with Jim and Stack, we're going to:

 - Make BatchUpdate a public class
 - Add timestamp to BatchUpdate
 - Add a commit() that takes a BatchUpdate
 - Deprecate commit() methods that take a timestamp parameter
 - Modify the communication between HTable and HRegionServer to use timestamp 
from BatchUpdate and remove timestamp parameter from batchUpdate

In the case of MapReduce jobs, you should build a BatchUpdate object with the 
row, timestamp, and puts/deletes you want, then emit it as the key with a small 
or empty value. BatchUpdate will implement WritableComparable so that 
BatchUpdates with the same row/timestamp can be merged and applied together.

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

Reply via email to