[
https://issues.apache.org/jira/browse/HBASE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-35:
-----------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed. Thanks for the patch Bryan.
Patch is great. Makes client easier to understand.
Few things:
+ You should just remove dross like this rather than comment it out:
{code}
+/* long lockid = t.startUpdate(newRegions[i].getRegionName());
t.put(lockid, COL_REGIONINFO, Writables.getBytes(
newRegions[i].getRegionInfo()));
- t.commit(lockid);
+ t.commit(lockid);*/
{code}
+ Someone put ^M's into HTable (Not you -- I'd suspect that PC user JK)
> [hbase] Make BatchUpdate public in the API
> ------------------------------------------
>
> Key: HBASE-35
> URL: https://issues.apache.org/jira/browse/HBASE-35
> Project: Hadoop HBase
> Issue Type: New Feature
> Components: client
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.2.0
>
> Attachments: 35-v2.patch, 35-v3.patch, 35.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.
