From user-return-33187-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu Apr 4 05:05:47 2013 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9582AFEA4 for ; Thu, 4 Apr 2013 05:05:47 +0000 (UTC) Received: (qmail 94966 invoked by uid 500); 4 Apr 2013 05:05:45 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 94864 invoked by uid 500); 4 Apr 2013 05:05:44 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 94822 invoked by uid 99); 4 Apr 2013 05:05:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Apr 2013 05:05:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [66.111.4.221] (HELO new1-smtp.messagingengine.com) (66.111.4.221) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Apr 2013 05:05:36 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A8125BC0 for ; Thu, 4 Apr 2013 01:05:15 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 04 Apr 2013 01:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=venarc.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=mesmtp; bh=4OHc6DWGO/skaBP8ay10AH96KqA=; b=ZvMPF rZWE6eAvffFBar/wgUYtM27pB7FETwxZOi45FnBjMr3ao1FXw7qPQea6i1Y9x8nE pEAm6UkB84DMiqefhqXJX8ZSJVDd5i6SB9U0o/Lf309OdkyDmtCCaGfaie1mAotG S035O97xtae9eAp8gYUKiV4OVMoZdPlTGv9iFM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; s=smtpout; bh=4OHc6DWGO /skaBP8ay10AH96KqA=; b=sIy7XmYm0WSMxeqzVIAr3HC9wU1+S2oh0nh2JTlGf 5s5NA85ee4XW+3VBZNlnUMxjtsl4T61PT4/1t9DAphUXTIWkx+40+io/SY3uSLU1 Wd+t5mXvxn6EmQdRCr7ODfydp+ceYD0hO+l9fOlPlImGjA7eKINfbfVFoGSl6Zvq /I= X-Sasl-enc: 2NW3lIcO6C3/0Y0OSn4tkxCayp3eKb60LlIk3KhS2j5M 1365051914 Received: from [192.168.1.2] (unknown [108.60.62.58]) by mail.messagingengine.com (Postfix) with ESMTPA id DB1462000FA for ; Thu, 4 Apr 2013 01:05:14 -0400 (EDT) From: Drew Kutcharian Content-Type: multipart/alternative; boundary="Apple-Mail=_22981DD4-D050-4CF6-AC52-65D769C6BE23" Message-Id: <271FCF3F-3F0E-41C1-AD67-5B35E6EB855C@venarc.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any plans for read-before-write update operations in CQL3? Date: Wed, 3 Apr 2013 22:05:13 -0700 References: <11C8B93C-00D6-4871-9050-1D710BA298C1@venarc.com> <9B65FDA2-7975-495A-B87F-5D0D013C9157@thelastpickle.com> To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_22981DD4-D050-4CF6-AC52-65D769C6BE23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I guess it'd be safe to say that the read consistency could be the same = as the consistency of the update. But regardless, that would be a lot = better than reading a value, modifying it at the client side and then = writing it back. On Apr 3, 2013, at 7:12 PM, Edward Capriolo = wrote: > Counters are currently read before write, some collection operations = on List are read before write. >=20 >=20 > On Wed, Apr 3, 2013 at 9:59 PM, aaron morton = wrote: > I would guess not.=20 >=20 >> I know this goes against keeping updates idempotent,=20 > There are also issues with consistency. i.e. is the read local or does = it happen at the CL level ?=20 > And it makes things go slower. >=20 >> We currently do things like this in client code, but it would be = great to be able to this on the server side to minimize the chance of = race conditions. > Sometimes you can write the plus one into a new column and then apply = the changes in the reading client thread.=20 >=20 > Cheers >=20 > ----------------- > Aaron Morton > Freelance Cassandra Consultant > New Zealand >=20 > @aaronmorton > http://www.thelastpickle.com >=20 > On 4/04/2013, at 12:48 AM, Drew Kutcharian wrote: >=20 >> Hi Guys, >>=20 >> Are there any short/long term plans to support UPDATE operations that = require read-before-write, such as increment on a numeric non-counter = column?=20 >> i.e.=20 >>=20 >> UPDATE CF SET NON_COUNTER_NUMERIC_COLUMN =3D = NON_COUNTER_NUMERIC_COLUMN + 1; >>=20 >> UPDATE CF SET STRING_COLUMN =3D STRING_COLUMN + "postfix"; >>=20 >> etc. >>=20 >> I know this goes against keeping updates idempotent, but there are = times you need to do these kinds of operations. We currently do things = like this in client code, but it would be great to be able to this on = the server side to minimize the chance of race conditions. >>=20 >> -- Drew >=20 >=20 --Apple-Mail=_22981DD4-D050-4CF6-AC52-65D769C6BE23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = guess it'd be safe to say that the read consistency could be the same as = the consistency of the update. But regardless, that would be a lot = better than reading a value, modifying it at the client side and then = writing it back.


On Apr 3, 2013, at = 7:12 PM, Edward Capriolo <edlinuxguru@gmail.com> = wrote:

Counters are currently read before write, = some collection operations on List are read before write.


On Wed, Apr 3, = 2013 at 9:59 PM, aaron morton <aaron@thelastpickle.com> wrote:
I would guess = not. 

I know = this goes against keeping updates idempotent, 
There are also issues with consistency. i.e. is the read local or does = it happen at the CL level ? 
And it makes things go = slower.

 We = currently do things like this in client code, but it would be great to = be able to this on the server side to minimize the chance of race = conditions.
Sometimes you can write the plus one into a new column and then apply = the changes in the reading client = thread. 

Cheers

-----------------
Aaron Morton
Freelance = Cassandra Consultant
New = Zealand

@aaronmorton

On 4/04/2013, at 12:48 AM, Drew Kutcharian <drew@venarc.com> = wrote:

Hi Guys,

Are there any = short/long term plans to support UPDATE operations that require = read-before-write, such as increment on a numeric non-counter column? =
i.e.

UPDATE CF SET NON_COUNTER_NUMERIC_COLUMN =3D = NON_COUNTER_NUMERIC_COLUMN + 1;

UPDATE CF SET STRING_COLUMN =3D = STRING_COLUMN + "postfix";

etc.

I know this goes against = keeping updates idempotent, but there are times you need to do these = kinds of operations. We currently do things like this in client code, = but it would be great to be able to this on the server side to minimize = the chance of race conditions.

-- = Drew


=

= --Apple-Mail=_22981DD4-D050-4CF6-AC52-65D769C6BE23--