[
https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548476
]
Bryan Duxbury commented on HADOOP-2348:
---------------------------------------
If we actually want to have the ability to have multiple updates in progress at
once, why don't we expose the BatchUpdate object, or better, create some sort
of Bigtable-esque RowMutation class that the users can create and then apply to
a table? It'd be nicer and more object-oriented than simply methods hanging off
of HTable and grouped by a random number.
> [hbase] lock_id in HTable.startUpdate and commit/abort is misleading and
> useless
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2348
> URL: https://issues.apache.org/jira/browse/HADOOP-2348
> Project: Hadoop
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Assignee: Jim Kellerman
> Priority: Minor
>
> In the past, the lock id returned by HTable.startUpdate was a real lock id
> from a remote server. However, that has been superceeded by the BatchUpdate
> process, so now the lock id is just an arbitrary value. More, it doesn't
> actually add any value, because while it implies that you could start two
> updates on the same HTable and commit them separately, this is in fact not
> the case. Any attempt to do a second startUpdate throws an
> IllegalStateException.
> Since there is no added functionality afforded by the presence of this
> parameter, I suggest that we overload all methods that use it to ignore it
> and print a deprecation notice. startUpdate can just return a constant like 1
> and eventually turn into a boolean or some other useful value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
