Good to hear, thanks. I didn't find that in my searches. On Feb 25, 2014 3:13 AM, "Sylvain Lebresne" <sylv...@datastax.com> wrote:
> You're running into https://issues.apache.org/jira/browse/CASSANDRA-6623. > It will be fixed in 2.0.6 but you can read the comments there for more > details. > > > On Tue, Feb 25, 2014 at 9:02 AM, J Robert Ray <jrobert...@gmail.com>wrote: > >> Thanks Daniel. >> >> I am taking care to only expire the one column. There are other columns >> so my row isn't completely deleted. >> On Feb 24, 2014 11:37 PM, "Daniel Shelepov" <dan...@timefork.com> wrote: >> >>> For the case where you don't get the update, is your whole row removed >>> when TTL expires? If so, you're essentially looking at a non-existing row, >>> and I think it's not too surprising that a "if col=null" test will behave >>> differently; I personally wouldn't call it a bug. If you're dealing with >>> disappearing rows, you should look into running INSERT IF NOT EXISTS >>> queries instead of UPDATE IF col=null. >>> >>> >>> >>> If the row is not completely deleted when TTL expires, then the behavior >>> is definitely fishy, and should probably be filed as a bug. >>> >>> >>> >>> To your other question, once a TTL update is expired, you can't infer >>> its past existence through any queries. >>> >>> >>> >>> Daniel >>> >>> >>> >>> *From:* J Robert Ray [mailto:jrobert...@gmail.com] >>> *Sent:* Monday, February 24, 2014 11:10 PM >>> *To:* user@cassandra.apache.org >>> *Subject:* Mixing CAS and TTL. >>> >>> >>> >>> Hi, I am trying to mix CAS and TTL and am wondering if this behavior >>> that I am seeing is expected. >>> >>> >>> >>> I'm on 2.0.2 and using the java datastax 2.0.0-rc3 client. >>> >>> >>> >>> In my application, a server "claims" a row by assigning a value to a row >>> using CAS, expecting the column to start out null. The column has a >>> shortish TTL and while the application "owns" the row, it will periodically >>> refresh the TTL on the column. If the application dies, the column expires >>> and can be claimed by another server. My problem is that after the TTL >>> expires, no server can successfully claim a row using a CAS update. >>> >>> >>> >>> If I set a TTL on a column with a null value (for demonstration >>> purposes; the real code sets to a non-null value): >>> >>> >>> >>> UPDATE foo USING TTL 120 SET col = null WHERE ...; >>> >>> >>> >>> This CAS update will succeed: >>> >>> >>> >>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = null; // >>> [applied] = true >>> >>> or >>> >>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = 'foo'; // >>> [applied] = true, col = null >>> >>> >>> >>> However, if I allow the TTL to expire, then the same update now fails. >>> >>> >>> >>> UPDATE foo USING TTL 120 SET col = 'some value' IF col = null; // >>> [applied] = false >>> >>> >>> >>> Note, after it fails, the ResultSet column definitions only contains >>> "[applied]" and so does not provide the value of the 'col' column which >>> failed the conditional update. >>> >>> >>> >>> It seems a null value is a different flavor of null than an expired >>> column. Is it possible to make an update conditional on if a column is >>> expired? Is this behavior expected or a bug? >>> >>> >>> >>> Thanks! >>> >> >
