[
https://issues.apache.org/jira/browse/HADOOP-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559143#action_12559143
]
Bryan Duxbury commented on HADOOP-2611:
---------------------------------------
Also note, this change would allow multiple "concurrent" updates to go on
against the same HTable instance at once, as the changes would be tracked in
the RowMutation instance, rather than internal to the HTable.
> [hbase] Create a RowMutation class in the public API
> ----------------------------------------------------
>
> Key: HADOOP-2611
> URL: https://issues.apache.org/jira/browse/HADOOP-2611
> Project: Hadoop
> Issue Type: New Feature
> Components: contrib/hbase
> Reporter: Bryan Duxbury
> Priority: Minor
>
> 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.
