[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629826#action_12629826
]
Jean-Daniel Cryans commented on HBASE-880:
------------------------------------------
Proposed RowOperation class:
{code}
public class RowOperation implements Writable {
private byte [] row;
private long timestamp = HConstants.LATEST_TIMESTAMP;
private long rowLock = -1L;
constructors, getters, setters, read, write...
}
{code}
Class to be used for gets:
{code}
public class RowGet extends RowOperation {
private byte[][] columns;
}
{code}
RowGet used in a get (in opposition to getRow) would only use the first column
in the byte array. Is it confusing?
BatchUpdate would now extend RowOperation (and maybe should be renamed?)
{code}
public class BatchUpdate implements Iterable<BatchOperation> {
private ArrayList<BatchOperation> operations =
new ArrayList<BatchOperation>();
}
{code}
Maybe we can do the same for scanners?
All methods in the API would use their corresponding class. All others would be
deprecated.
> 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
> Fix For: 0.19.0
>
>
> 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.