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