Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <390558343.1222810664466.JavaMail.jira@brutus>
Date: Tue, 30 Sep 2008 14:37:44 -0700 (PDT)
From: "Jim Kellerman (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-880) Improve the current client API by
 creating new container classes
In-Reply-To: <1824320241.1221058724990.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-880?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12635=
866#action_12635866 ]=20

Jim Kellerman commented on HBASE-880:
-------------------------------------

@Stack

{quote}
 Neither the current API nor the 880 patch supports different timestamps fo=
r update, get(column) or getRow. Are you proposing we add this?

Do=C4=9Facan G=C3=BCney did over in HBASE-899. There you were thinking it w=
ould not be too difficult to add? Seems reasonable to me: i.e. timestamp
does not below with row but rather with column specification.
{quote}

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

{quote}
I see now how my comment confused things by grouping get with put and delet=
e. 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 th=
e one operation. That 'normal').
{quote}

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

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

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-v=
2.patch, hbase_client_classes.png, proposed.jpg
>
>
> The current API does not scale very well. For each new feature, we have t=
o add many methods to take care of all the overloads. Also, the need to bat=
ch row operations (gets, inserts, deletes) implies that we have to manage s=
ome "entities" like we are able to do with BatchUpdate but not with the oth=
er operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another featur=
e-compatible one, other methods will be added in other issues.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.