hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Kellerman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Tue, 30 Sep 2008 21:37:44 GMT

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

Jim Kellerman commented on HBASE-880:


 Neither the current API nor the 880 patch supports different timestamps for update, get(column)
or getRow. Are you proposing we add this?

Doğacan Güney did over in HBASE-899. There you were thinking it would not be too difficult
to add? Seems reasonable to me: i.e. timestamp
does not below with row but rather with column specification.

It should be easy enough to add. Does it make sense for all of get/put/delete?

I see now how my comment confused things by grouping get with put and delete. Pardon me. What
I meant was that when updating, you should
be able to mix put and delete operations on the one row and asking if this redesign allowed
that. Seems like I can make RowMutation object and
do deletes and puts against the one row (You can't do get and updates in the one operation.
That 'normal').

Yes, you can do both puts and deletes in one operation.

Regards the proposal, if I want to get values for many columns - not all columns on a row
but some subset - how do I do it? I use a
RowGetOperation instead of a GetOperation? We should have better naming, don't you think?
Should we drop the GetOperation
and instead rename current RowGetOperation as GetOperation and use it everywhere? (If we do
this, we won't be able to do
hbase-899 as written?)

I kind of struggled with this one, and it ended up the way it did since you asked that get
return Cell[] instead of RowResult. I would
prefer that we drop GetOperation and rename RowGetOperation to GetOperation, if you think
that it's ok for a single get to return
SortedMap<byte[], Cell> instead of Cell[], it's an easy change and enables folding AbstractGetOperation
into the new GetOperation
as well. I can certainly draw it up and we can see which we like better.

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