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 74013F662 for ; Fri, 26 Apr 2013 15:48:47 +0000 (UTC) Received: (qmail 87286 invoked by uid 500); 26 Apr 2013 15:48:45 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 87256 invoked by uid 500); 26 Apr 2013 15:48:45 -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 87247 invoked by uid 99); 26 Apr 2013 15:48:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Apr 2013 15:48:45 +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 (athena.apache.org: domain of shsedghi@gmail.com designates 209.85.210.182 as permitted sender) Received: from [209.85.210.182] (HELO mail-ia0-f182.google.com) (209.85.210.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Apr 2013 15:48:40 +0000 Received: by mail-ia0-f182.google.com with SMTP id w33so1465835iag.27 for ; Fri, 26 Apr 2013 08:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=RhIUlOTRExtKOvbXpGr6YQxIn4ZhnihJKbnI6WOMh94=; b=TRI2g9Co3jDewOQjaIlht4UlFSKnIKw1b/2wlS5iK2j6mNQRuxyt55vPI/J8Le0Cmq hyIFBHXXsk9YQwo+PNHN9o4/OqTF1JJjAvSIK/8exo0CGqcN7d5Ck+/AF5/iadUtjlQ+ sefV6Bp4sc3bCUyZm/rmWFI+zL4gWvAbbGRte4youxp3P51d/G9IIrIhEtF0U9OmSAjF P8zW/uvazcSQIE3Am1aTEN3EM6IbuvMOqTxXv+qDhfcEAR/JR/aL+zAt+nK+39GYaXr2 dMc4o+a3JAmaFXv3k63AcBNWtGNu6TiPpCzJvqMSw2wcayoFXbBWIX/esbZuBm68GNgS HPmQ== MIME-Version: 1.0 X-Received: by 10.50.141.129 with SMTP id ro1mr2222530igb.39.1366991300393; Fri, 26 Apr 2013 08:48:20 -0700 (PDT) Received: by 10.64.32.131 with HTTP; Fri, 26 Apr 2013 08:48:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Apr 2013 11:48:20 -0400 Message-ID: Subject: Re: CQL update and TTL From: Shahryar Sedghi To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e01536ab0df06fa04db457649 X-Virus-Checked: Checked by ClamAV on apache.org --089e01536ab0df06fa04db457649 Content-Type: text/plain; charset=ISO-8859-1 Thanks Sylvain So how to avoid the prepared statement cache exhaustion, is there a way to either make TTL dynamic (using ?) or tell the engine not to cache the Prepared statement. I am using the new CQL Java Driver. Shahryar On Fri, Apr 26, 2013 at 11:42 AM, Sylvain Lebresne wrote: > This is indeed intended. That behavior is largely dictated by how the > storage engine works, and the fact that an update does no read internally > in particular. > > Yet, what I do not know is whether this behavior can be changed somehow to >> let the initial TTL, >> > > There's nothing like that supported, no. You have to read the value first > to get his TTL and then insert whatever update you want with the TTL you've > just fetch. And since we don't have a good way to do it much more > efficiently than server side, we prefer not doing it. That way the > performance impact is very explicit. > > -- > Sylvain > > > >> >> Alain >> >> >> 2013/4/26 Shahryar Sedghi >> >>> Apparently when I update a column using CQL that already has a TTL, it >>> resets the TTL to null, so if there was already a TTL for all columns that >>> I inserted part of a composite column set, this specific column that I >>> updated will not expire while the others are are getting expired. Is it how >>> it is expected to work or it is a bug? >>> >>> Thanks in advance >>> >>> Shahryar >>> >>> >>> >> > -- "Life is what happens while you are making other plans." ~ John Lennon --089e01536ab0df06fa04db457649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Sylvain

So how to avoid the prepared st= atement cache exhaustion, is there a way to either make TTL dynamic=A0 (usi= ng ?) or tell the engine not to cache the Prepared statement. I am using th= e new CQL Java Driver.

Shahryar


On Fri, Apr 26, 2013 at 11:42 AM, Sylvain Lebresne <sy= lvain@datastax.com> wrote:
This is indeed intended. Th= at behavior is largely dictated by how the storage engine works, and the fa= ct that an update does no read internally in particular.

Yet, what I do not know is = whether this behavior can be changed somehow to let the initial TTL,
<= /blockquote>

There's nothing like that supported, no. You = have to read the value first to get his TTL and then insert whatever update= you want with the TTL you've just fetch. And since we don't have a= good way to do it much more efficiently than server side, we prefer not do= ing it. That way the performance impact is very explicit.

--
Sylvain=A0
=A0
=

Alain


2013/4/26 Shahryar Sedghi <shs= edghi@gmail.com>
Apparently when I= update a column using CQL that already has a TTL, it resets the TTL to nul= l, so if there was already a TTL for all columns that I inserted part of a = composite column set, this specific column that I updated will not expire w= hile the others are are getting expired. Is it how it is expected to work o= r it is a bug?

Thanks in advance

Shahryar







--
"Life is what happ= ens while you are making other plans." ~ John Lennon --089e01536ab0df06fa04db457649--