From user-return-34695-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Jun 19 10:29:38 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 445A7C841 for ; Wed, 19 Jun 2013 10:29:38 +0000 (UTC) Received: (qmail 40354 invoked by uid 500); 19 Jun 2013 10:29:31 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 40334 invoked by uid 500); 19 Jun 2013 10:29:31 -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 40324 invoked by uid 99); 19 Jun 2013 10:29:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jun 2013 10:29:31 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS,T_FILL_THIS_FORM_SHORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [203.199.18.84] (HELO mail1.impetus.co.in) (203.199.18.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jun 2013 10:29:27 +0000 Received: from MAIL3.impetus.co.in ([fe80::443f:4f25:6889:b268]) by mail1.impetus.co.in ([fe80::4c95:4ec3:183e:2d3%15]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 15:59:03 +0530 From: Amresh Kumar Singh To: "user@cassandra.apache.org" Subject: RE: TTL can't be speciefied at column level using CQL 3 in Cassandra 1.2.x Thread-Topic: TTL can't be speciefied at column level using CQL 3 in Cassandra 1.2.x Thread-Index: Ac5s0RpWJzJnN70TT/emVK9mkSKZv///rY+AgABdd7Q= Date: Wed, 19 Jun 2013 10:29:03 +0000 Message-ID: <8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE69@Mail3.impetus.co.in> References: <8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE03@Mail3.impetus.co.in>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.145.66] Content-Type: multipart/alternative; boundary="_000_8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE69Mail3impetuscoi_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE69Mail3impetuscoi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Sylvian, I am working on a high level client (Kundera) which, if users want, should = be able to achieve this, even if that's uncommon. Writing Update Batch CQL is an approach that works, as you are saying perfo= rmance is not impacted. In my opinion, an *optional* "USING TTL" with column values (in addition to= existing syntax) won't hurt. In most of the cases people won't need this, = but if they do, it will be there. In the meantime, I am going to try approach you suggested. Thanks again! Sincerely, Amresh ________________________________ From: Sylvain Lebresne [sylvain@datastax.com] Sent: Wednesday, June 19, 2013 3:45 PM To: user@cassandra.apache.org Subject: Re: TTL can't be speciefied at column level using CQL 3 in Cassand= ra 1.2.x Hi, > But CQL3 doesn't provide a way for this. That's not true. But the syntax is probably a bit more verbose than what yo= u were hoping for. Your example (where I assume user_name is you partition ke= y) can be achieved with: BEGIN BATCH UPDATE users SET password =3D 'aaaaaa' WHERE user_name=3D'xamry' USING = TTL 44444; UPDATE users SET gender =3D 'm' WHERE user_name=3D'xamry' USING = TTL 11111; UPDATE users SET state =3D 'UP' WHERE user_name=3D'xamry' USING = TTL 66666; APPLY BATCH; Granted that is a tad verbose, but in term of the actual query performed th= is is *absolutely* equivalent to what you would do in thrift. So should we provide a shorter syntax to achieve this? It's worth discussin= g and nobody said CQL3 is not meant to evolve. Though my initial opinion on t= his is that setting different TTL on different columns in the same CQL3 row and= the same query is probably not all that common overall, so I'm not totally convinced it's worth adding complexity to the syntax for such a shortcut (y= es, a shorter syntax would mean less bytes to transfer to the server for the qu= ery and less to parse but if you care about performance you should be using prepared statement which makes that issue moot). -- Sylvain On Wed, Jun 19, 2013 at 11:40 AM, Amresh Kumar Singh > wrote: Hi, Using Thrift, we are allowed to specify different TTL values for each colum= ns in a row. But CQL3 doesn't provide a way for this. For instance, this is allowed: INSERT INTO users (user_name, password, gender, state) VALUES ('xamry2, 'a= aaaaa', 'm', 'UP') using TTL 50000; But something like this is not achievable: INSERT INTO users (user_name, password, gender, state) VALUES ('xamry' usi= ng TTL 33333, 'aaaaaa' using TTL 4444, 'm' using TTL 1111, 'UP' using TTL 6= 666); Why is such inconsistency. Should we not be able to achieve this using CQL = looking at the fact that CQL usage is encouraged as a replacement for Thrif= t. Sincerely, Amresh ________________________________ NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. ________________________________ NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE69Mail3impetuscoi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Sylvian,

I am working on a high level client (Kundera) which, if users want, should = be able to achieve this, even if that's uncommon.

Writing Update Batch CQL is an approach that works, as you are saying perfo= rmance is not impacted.

In my opinion, an *optional* "USING TTL" with column values (in a= ddition to existing syntax) won't hurt. In most of the cases people won't n= eed this, but if they do, it will be there.

In the meantime, I am going to try approach you suggested. Thanks again!
Sincerely,
Amresh

From: Sylvain Lebresne [sylvain@datastax.co= m]
Sent: Wednesday, June 19, 2013 3:45 PM
To: user@cassandra.apache.org
Subject: Re: TTL can't be speciefied at column level using CQL 3 in = Cassandra 1.2.x

Hi,

> But CQL3 doesn't provide a way for this.

That's not true. But the syntax is probably a bit more verbose than wh= at you
were hoping for. Your example (where I assume user_name is you partiti= on key)
can be achieved with:
  BEGIN BATCH
    UPDATE users SET password =3D 'aaaaaa' WHERE user_name= =3D'xamry' USING TTL 44444;
    UPDATE users SET gender =3D 'm'       &nb= sp;WHERE user_name=3D'xamry' USING TTL 11111;
    UPDATE users SET state =3D 'UP'       &nb= sp;WHERE user_name=3D'xamry' USING TTL 66666;
  APPLY BATCH;

Granted that is a tad verbose, but in term of the actual query perform= ed this
is *absolutely* equivalent to what you would do in thrift.

So should we provide a shorter syntax to achieve this? It's worth disc= ussing
and nobody said CQL3 is not meant to evolve. Though my initial opinion= on this
is that setting different TTL on different columns in the same CQL3 ro= w and the
same query is probably not all that common overall, so I'm not totally=
convinced it's worth adding complexity to the syntax for such a shortc= ut (yes,
a shorter syntax would mean less bytes to transfer to the server for t= he query
and less to parse but if you care about performance you should be usin= g
prepared statement which makes that issue moot).

--
Sylvain



On Wed, Jun 19, 2013 at 11:40 AM, Amresh Kumar S= ingh <amresh.= singh@impetus.co.in> wrote:
Hi,

Using Thrift, we are allowed to specify different TTL values for each colum= ns in a row.

But CQL3 doesn't provide a way for this.

For instance, this is allowed:
INSERT INTO users (user_name, password, gender, state)  VALUES ('xamry= 2, 'aaaaaa', 'm', 'UP') using TTL 50000;

But something like this is not achievable:
INSERT INTO users (user_name, password, gender, state)  VALUES ('xamry= ' using TTL 33333, 'aaaaaa' using TTL 4444, 'm' using TTL 1111, 'UP' using = TTL 6666);


Why is such inconsistency. Should we not be able to achieve this using CQL = looking at the fact that CQL usage is encouraged as a replacement for Thrif= t.

Sincerely,
Amresh









NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference.









NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference.
--_000_8645D40887F5104F9B94D1AC7A3D1FA5DB1CFE69Mail3impetuscoi_--