Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 216.239.58.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=dwXP6GL1FyuiH+AnS5/CNbYtbQ9mXXNRnE8zMep2g4vBKklbgmlTHqH6qJR9HEuoRe
         2KFOzPPwdVixeBIK917mRYX+GO0Oqhh7ygWIZwWjzN2jDpjUFezMMBBcA89AH36A5Lco
         tw9X5k8sCy1Z6sQpRbcNoPESTqccTwraAvYoA=
MIME-Version: 1.0
In-Reply-To: <a1625f290911090846p6846739cg276195174268c36d@mail.gmail.com>
References: <a1625f290911082057k2e66bbdwff5dbe2fabe7d89b@mail.gmail.com>
	<ff1a07b80911090243x4a8d6a75r408f36c2e073dc79@mail.gmail.com>
	<a1625f290911090846p6846739cg276195174268c36d@mail.gmail.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Mon, 9 Nov 2009 10:53:31 -0600
Message-ID: <e06563880911090853u2d644ba0qb1c0bdb955f5a6e4@mail.gmail.com>
Subject: Re: why does remove need a timestamp?
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

wiki is publicly editable, just click Login to create account

On Mon, Nov 9, 2009 at 10:46 AM, Ramzi Rabah <rrabah@playdom.com> wrote:
> Makes lots of sense.
> It would be nice to update the API wiki for remove:
> http://wiki.apache.org/cassandra/API
>
> with these details, since the current wording is potentially vague and
> misleading.
>
> Thanks guys
> Ray
>
> On Mon, Nov 9, 2009 at 2:43 AM, Mark Robson <markxr@gmail.com> wrote:
>>
>>
>> 2009/11/9 Ramzi Rabah <rrabah@playdom.com>
>>>
>>> Hello all:
>>> I am confused about the need of passing a =A0timestamp for the remove
>>> operation. Why does the remove operation in Cassandra require a
>>> timestamp? What happens if I provide a remove call with a different
>>> timestamp than what I inserted, will the row still be deleted?
>>
>> It is so that if the commands are replayed in a different order on diffe=
rent
>> nodes, the same result is produced.
>>
>> Remove only removes values which have a timestamp of before or the same =
as
>> the one provided - this is essential, as if a "later" insert "overtakes"=
 the
>> remove, the remove needs to avoid removing "newer" data.
>>
>> The eventual consistency model only works (i.e. only produces consistenc=
y)
>> if mutations have the same effect regardless of the order they are appli=
ed
>> in.
>>
>> That is my understanding anyway.
>>
>> Mark
>>
>