[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635586#action_12635586
]
Jim Kellerman commented on HBASE-880:
-------------------------------------
Ok, scratch my comment above which redesigns RowOperation and adds new classes.
RowOperation is basically fine as it is
- both get and update currently support one time stamp so keeping it in
RowOperation is fine.
- however do add another constructor (or two) in which you can specify the
RowLock.
I would eliminate RowSingleColumnOperation and RowGetRow and modify RowGet to
have
{code}
private byte[][] columns;
private int numVersions;
{code}
(to support HBASE-847and its sub tasks we could add another member, private
long startTimestamp, to support getting
values between two timestamps)
public Cell[] get(RowGet) would ensure that columns.length == 1
public RowResult getRow(RowGet) could be changed to return
HBaseMapWritable<byte[], Cell>
Eliminate RowDelete.
Deprecate BatchOperation.
Rename RowUpdate to RowMutation.
Add new class similar to BatchOperation and ColumnMutation above so that it can
handle both updates and deletes.
(It could be a private inner class to RowMutation) To support HBASE-847, we'd
need to add numVersions and
startTimestamp to this class. This would eliminate deleteAll and deleteFamily
and all changes to a row would be
done via commit.
That sound better?
> Improve the current client API by creating new container classes
> ----------------------------------------------------------------
>
> Key: HBASE-880
> URL: https://issues.apache.org/jira/browse/HBASE-880
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: client
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Fix For: 0.19.0
>
> Attachments: hbase-880-v1.patch, hbase-880-v2.patch
>
>
> The current API does not scale very well. For each new feature, we have to
> add many methods to take care of all the overloads. Also, the need to batch
> row operations (gets, inserts, deletes) implies that we have to manage some
> "entities" like we are able to do with BatchUpdate but not with the other
> operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another
> feature-compatible one, other methods will be added in other issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
