[ 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.