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 Thu, 02 Oct 2008 19:25:44 GMT

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

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

bq. Another objection I was going to make but having thought about it, I've not raised it
since it verges on the 'silly' relates to the Scanner API. Getting a scanner using a Scope
that does not include column/family name would make it impossible specifying a scanner that
took multiple columns and for each its own column Scope. Do we want to support this? If not,
the new API would allow a single Scope across all columns.

I am not sure I follow you here. Scanners can just have two constructors. One would just get
a scope (meaning that this scope is valid for all columns) and the other would get (again)
a Map of column, scope pairs. Or is there something I am missing here?

> 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