hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doğacan Güney (JIRA) <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Tue, 07 Oct 2008 22:02:46 GMT

    [ https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637675#action_12637675
] 

Doğacan Güney commented on HBASE-880:
-------------------------------------

bq. I'm really not happy where this is going... What would normally take a single line now
requires many object instantiations and I have to manage the single Cell get all over the
place. The patch I attached is not complete and should be used to see current proposal usage.


Well maybe a way of dealing with it can be hiding scopes and HbaseMapWritable-s from users
as much as possible. Something like:

{code}
Get get = new Get(row);
get.setTimestamp(col1, timestamp1);
get.setTimestamp(col2, timestamp2);
get.setVersions(col2, numVersions);

......

get.setAllTimestamps(timestamp); // for all columns

......

// maybe also add a constructor overload similar to current API
Get get = new Get(row, cols /* array of byte arrays */, timestamp);

{code}

> 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-patch.jpg, hbase-880-proposal4.patch, hbase-880-v1.patch,
hbase-880-v2.patch, hbase_client_classes.png, NewCilentAPIProposoal4.gif, proposal2.jpg, proposed.jpg
>
>
> 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