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 Tue, 07 Oct 2008 18:18:46 GMT

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

Jean-Daniel Cryans commented on HBASE-880:

I have some issues with current design :

- My opinion is that when upgrading to 0.19.0 people will find it strange that when using
a simple get() for a single cell they would now have to handle a SortedMap
- Also, a SortedMap is not as friendly as something called "RowResult". IMO the 0.1 API was
hard to use, 0.2 was way better and this would be like getting back to 0.1. This gets uglier
when we will be batching gets (returning a SortedMap of SortedMaps?)
- Regards HRS.get(), should we drop it since we merge get and getRow?
- How do we get a whole row a latest timestamp? Stack wrote that we should pass a null list
of Scopes but with the map thing it doesn't make much sense... Or do we fix it server-side
when we see no scope?

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

View raw message