Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of jon@cloudera.com designates
 209.85.212.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <503f3839.03ca320a.46c2.0026SMTPIN_ADDED@mx.google.com>
References: <Ac2GlUUKZCQp8FeRSH+Hr6N+L2+uHQ==>
 <503f3839.03ca320a.46c2.0026SMTPIN_ADDED@mx.google.com>
From: Jonathan Hsieh <jon@cloudera.com>
Date: Thu, 30 Aug 2012 05:52:13 -0700
Message-ID: 
 <CAAha9a0=9WgjyVwufbkb+GPa8i+zja3H6ssQ5149stisnrFEyQ@mail.gmail.com>
Subject: Re: Refactoring checkAndPut and checkAndDelete to use
 doMiniBatchMutation
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=bcaec51a8de628c3c404c87b267d

--bcaec51a8de628c3c404c87b267d
Content-Type: text/plain; charset=ISO-8859-1

Ram,

+1

It would be great if the refactor made adding a "checkAndMututate" method
trivial to add.  This method would do an  atomic check and set that and if
successful allowed for atomic deletions and puts on the same row.  (current
api only allow checkAndDelete, checkAndPut, and batchMutate).

Jon.

On Thu, Aug 30, 2012 at 2:53 AM, Ramkrishna.S.Vasudevan <
ramkrishna.vasudevan@huawei.com> wrote:

> Hi
>
>
>
> Currently the checkAndPut and checkAndDelete api internally calls the
> internalPut and internalDelete.  May be we can just call
> doMiniBatchMutation
> only.  This will help in future like if we have some hooks and the CP
> handles certain cases in the doMiniBatchMutation the same can be done while
> doing a put thro checkAndPut or while doing a delete thro checkAndDelete.
>
>
>
> If we are fine with this I can raise a JIRA and submit a patch which should
> be a simple one.
>
>
>
> Regards
>
> Ram
>
>


-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

--bcaec51a8de628c3c404c87b267d--