[
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)
