[
https://issues.apache.org/jira/browse/CASSANDRA-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239869#comment-14239869
]
Andrew Garrett commented on CASSANDRA-8430:
-------------------------------------------
[~aboudreault] Although that surprises me, it explains what I was seeing, sort
of. I also perceived confusing behavior when it came to setting things to null:
if I set everything to null on a row in a table where there were no primitive
types like bigint then the row would remain, and its contents would all be
null. But if I did this on a row that did contain primitive types then the row
would be removed. On the other hand, in both cases, TTLs would purge the column
as expected, but my understanding is that TTLs mark a column with a tombstone
whereas setting things to null just... sets them to null. So I don't understand
this behavior and I also don't understand why, if the primary key isn't a
normal column, it will remain around as long as the row doesn't contain
primitives in this case I'm explaining. These two situations feel related, are
they?
> 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)
