hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Thu, 02 Oct 2008 18:11:44 GMT

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

stack commented on HBASE-880:
-----------------------------

Thinking on it, the 'Doğacan Güney - 02/Oct/08 02:27 AM' suggestion looks like an improvement.
 We'd just move column/family specification out of Scope and have it supplied instead as Map
key (Map should probably be Sorted?  An HbaseMapWritable?).  Here is one reason why we might
NOT do this:

Clients might want to specify multiple scopes against a single column:  Imagine an application
that adds hundreds of updates to a column each day.  Client then wants to query for every
entry made at 12:00 over the last week or every hour over last day.

A 'workaround' would be to batch a set of Gets with an entry for every update wanted.

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.

On the one hand the Doğacan suggestion makes Get/Delete look like Put in that they too take
maps keyed by columns.  Thats good.

On other hand, we limit the perverse things a Client might want to do all in the one row Get/Delete
context.

I'm +1 on the Doğacan suggestion because it reduces complexity (I do not want to be in a
position where we are debugging a scan across 100 columns each with 100 Scopes and a user
'thinks' its not doing the right thing).

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


Mime
View raw message