cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8430) Updating a row that has a TTL produce unexpected results
Date Wed, 10 Dec 2014 08:18:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240804#comment-14240804
] 

Sylvain Lebresne commented on CASSANDRA-8430:
---------------------------------------------

bq. Now at first the row has 'abc', 2, 'whatever', then after the update it has 'abc', 0,
'whatever'.

If that was the case, that would be a bug, setting foo to {{null}} is not equivalent to setting
it to {{0}}. But  if you say use the java driver and do a {{getInt()}} to fetch the value
of {{foo}}, that method will return {{0}} for a {{null}} value because it return unboxed values
(there's a {{isNull()}} method to check if it's actually {{null}}). So make sure this is not
just what you're running into.

bq. It seems there's a difference between insert and update

There is one. An insert kind of set the primary key columns on their own, while update doesn't,
which means that after an insert a row will continue to exist even if you remove all non-PK
columns, while it won't with an update. Which is exactly what you're observing.

Now, none of that are bugs of Cassandra, so if you have further questions on behaviors, would
you mind moving the conversation to the user mailing list (if only because answers might be
profitable to more people there)?

> Updating a row that has a TTL produce unexpected results
> --------------------------------------------------------
>
>                 Key: CASSANDRA-8430
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8430
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Alan Boudreault
>              Labels: cassandra, ttl
>             Fix For: 2.0.11, 2.1.2, 3.0
>
>         Attachments: test.sh
>
>
> Reported on stackoverflow: http://stackoverflow.com/questions/27280407/cassandra-ttl-gets-set-to-0-on-primary-key-if-no-ttl-is-specified-on-an-update?newreg=19e8c6757c62474985fef7c3037e8c08
> I can reproduce the issue with 2.0, 2.1 and trunk. I've attached a small script to reproduce
the issue with CCM, and here is it's output:
> {code}
> aboudreault@kovarro:~/dev/cstar/so27280407$ ./test.sh 
> Current cluster is now: local
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
>  pk | bar  | foo
> ----+------+-----
>   1 | test |   1
> (1 rows)
> Update data with no TTL
> UPDATE ks.tbl set bar='change' where pk=1;
> sleep 6 sec
> BUG: Row should be deleted now, but isn't. and foo column has been deleted???
>  pk | bar    | foo
> ----+--------+------
>   1 | change | null
> (1 rows)
> Insert data with a 5 sec TTL
> INSERT INTO ks.tbl (pk, foo, bar) values (1, 1, 'test') using TTL 5;
>  pk | bar  | foo
> ----+------+-----
>   1 | test |   1
> (1 rows)
> Update data with a higher (10) TTL
> UPDATE ks.tbl USING TTL 10 set bar='change' where pk=1;
> sleep 6 sec
> BUG: foo column has been deleted?
>  pk | bar    | foo
> ----+--------+------
>   1 | change | null
> (1 rows)
> sleep 5 sec
> Data is deleted now after the second TTL set during the update. Is this a bug or the
expected behavior?
> (0 rows)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message