Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 11 Oct 2011 17:51:12 +0000 (UTC)
From: "Jonathan Gray (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1618048595.1678.1318355472208.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1269439512.15619.1310689082368.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4102) atomicAppend: A put that appends to
 the latest version of a cell; i.e. reads current value then adds the bytes
 offered by the client to the tail and writes out a new entry
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-4102?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1312=
5225#comment-13125225 ]=20

Jonathan Gray commented on HBASE-4102:
--------------------------------------

This is really nice Lars.  I'd love to see integration with RWCC and to som=
ehow unify the code with Increment.  But I'm okay with committing this and =
filing a follow-up JIRA.

I'm also going to backport this into my local 92 branch but I think it shou=
ld only be committed to trunk.  Let's put all the polish on before putting =
it in an official release.

Nice work!
               =20
> atomicAppend: A put that appends to the latest version of a cell; i.e. re=
ads current value then adds the bytes offered by the client to the tail and=
 writes out a new entry
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-----------------------
>
>                 Key: HBASE-4102
>                 URL: https://issues.apache.org/jira/browse/HBASE-4102
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: stack
>            Assignee: Lars Hofhansl
>         Attachments: 4102-v1.txt, 4102.txt
>
>
> Its come up a few times that clients want to add to an existing cell rath=
er than make a new cell each time.  At our place, the frontend keeps a list=
 of urls a user has visited -- their md5s -- and updates it as user progres=
ses.  Rather than read, modify client-side, then write new value back to hb=
ase, it would be sweet if could do it all in one operation in hbase server.=
  TSDB aims to be space efficient.  Rather than pay the cost of the KV wrap=
per per metric, it would rather have a KV for an interval an in this KV hav=
e a value that is all the metrics for the period.
> It could be done as a coprocessor but this feels more like a fundamental =
feature.
> Beno=C3=AEt suggests that atomicAppend take a flag to indicate whether or=
 not the client wants to see the resulting cell; often a client won't want =
to see the result and in this case, why pay the price formulating and deliv=
ering a response that client just drops.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira