incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amresh Kumar Singh <amresh.si...@impetus.co.in>
Subject RE: TTL can't be speciefied at column level using CQL 3 in Cassandra 1.2.x
Date Wed, 19 Jun 2013 10:29:03 GMT
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 performance 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 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 what you
were hoping for. Your example (where I assume user_name is you partition key)
can be achieved with:
  BEGIN BATCH
    UPDATE users SET password = 'aaaaaa' WHERE user_name='xamry' USING TTL 44444;
    UPDATE users SET gender = 'm'        WHERE user_name='xamry' USING TTL 11111;
    UPDATE users SET state = 'UP'        WHERE user_name='xamry' USING TTL 66666;
  APPLY BATCH;

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

So should we provide a shorter syntax to achieve this? It's worth discussing
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 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 (yes,
a shorter syntax would mean less bytes to transfer to the server for the query
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 <amresh.singh@impetus.co.in<mailto:amresh.singh@impetus.co.in>>
wrote:
Hi,

Using Thrift, we are allowed to specify different TTL values for each columns 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, '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 Thrift.

Sincerely,
Amresh


________________________________






NOTE: This message may contain information that is confidential, proprietary, privileged or
otherwise protected by law. The message is intended solely for the named addressee. If received
in error, please destroy and notify the 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 maintained nor that the communication is free of errors, virus, interception
or interference.


________________________________






NOTE: This message may contain information that is confidential, proprietary, privileged or
otherwise protected by law. The message is intended solely for the named addressee. If received
in error, please destroy and notify the 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 maintained nor that the communication is free of errors, virus, interception
or interference.

Mime
View raw message