hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Wed, 10 Sep 2008 15:08:44 GMT

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


Mime
View raw message