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 Wed, 08 Oct 2008 21:17:44 GMT

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

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

>From IRC with Do─čacan:
{code}
[13:10]	<dogacan>	st^ack: maybe I am just being thick, but I don't understand why exposing
Specification or Scope is useful than just doing get.setTimestamp(col, timestamp) ?
[13:22]	<st^ack>	I thought point of latest proposal was extraction of the Specification/Scope
object.
[13:23]	<st^ack>	When you add the getters/setters back to Get and Delete (but not to
Put because it doesn't have Specification/Scope), then the advantage of the last proposal
goes away?
[13:25]	<st^ack>	If the setting is done against Specification, then Get/Delete/Put can
be immutable and all treated the same.
[13:51]	<dogacan>	hmm
[13:51]	<dogacan>	I see
[13:52]	<dogacan>	i forgot about trying to make get/delete/put as similar as possible
:)
[13:52]	<dogacan>	let me think about it, thanks
{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