Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <10901470.1201552654013.JavaMail.jira@brutus>
Date: Mon, 28 Jan 2008 12:37:34 -0800 (PST)
From: "stack (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-2611) [hbase] Create a RowMutation class
 in the public API
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HADOOP-2611:
-------------------------------

You should have your constructors cascade rather than dupe setup code: i.e. RowMutation(Text) should call RowMutation(Text, long) (You write super(row, HConstants.LATEST_TIMESTAMP).

You could also make the data members final -- i.e. RowMutation timestamp and row are passed on construction and thereafter cannot be changed.

IMO, declaration and assignment all on the one line is easier on the reader as in:

{code}
private Map<Text, byte[]> mutations = new HashMap<Text, byte[]>();
{code}

Timestamp should be LATEST_TIMESTAMP rather than -1L.

Is convertToBatchUpdate temporary? Do you intend on making it so servers take RowMutations, or, easier, why not let out BatchUpdate?  Is RowMutation different in any way other than in name?

> [hbase] Create a RowMutation class in the public 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
>            Priority: Minor
>         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.