[
https://issues.apache.org/jira/browse/CASSANDRA-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8042.
-----------------------------------------
Resolution: Not a Problem
bq. but such behavior looks (just looks) inconsistent
I'm not sure I agree. If you do
{noformat}
INSERT INTO tt (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3') USING TTL 20;
{noformat}
you're explicitely mentioning your static column {{cs}}, so it makes sense imo
that the TTL is applied to it. If you do
{noformat}
DELETE FROM tt1 WHERE c1='1' AND c2 = '1-2';
{noformat}
however, you're not explicitly listing any columns. If you were listing columns
explicitely, i.e. if you do:
{noformat}
DELETE c3, cs FROM tt1 WHERE c1='1' AND c2 = '1-2';
{noformat}
then it will delete {{cs}} and be consistent with the {{INSERT}} case.
Deleting a row without listing static columns explicitely does not delete the
static columns. Maybe that behavior is not completely intuitive (but it's more
useful that way in practice in most usage of static columns) but I wouldn't say
it brings inconsistencies with ttls per se.
In any case, it's working as designed so unless someone has a concrete
suggestion/rational for changing the design, I'm closing as "not a problem".
bq. is it possible to insert a row with TTL but not to define TTL for static
column without using batches?
It's not (but it's not like there is any downside to using batches in such case
so ...).
> Inconsistent static column behavior after row deletion
> ------------------------------------------------------
>
> Key: CASSANDRA-8042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8042
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: viasyn
> Fix For: 2.1.1
>
>
> I've a table with static column defined. I'm inserting some rows with TTL
> defined, then one of row expires TTL of all the rows with same PK turns into
> null:
> {code}
> cqlsh:test> create table tt ( c1 text , c2 text , c3 text, cs text static,
> PRIMARY KEY (c1, c2) );
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-1', 'x', 's1')
> USING TTL 10;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-2', 'x', 's2')
> USING TTL 5;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3')
> USING TTL 20;
> cqlsh:test> insert into tt (c1, c2, c3, cs) VALUES ( '1', '1-4', 'x', 's4')
> USING TTL 3;
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> ----+-----+----+----
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> ----+-----+----+----
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> select * from tt;
> c1 | c2 | cs | c3
> ----+-----+------+----
> 1 | 1-1 | null | x
> 1 | 1-2 | null | x
> 1 | 1-3 | null | x
> (3 rows)
> {code}
> Same scenario with manual DELETion leads to another result:
> {code}
> cqlsh:test> create table tt1 ( c1 text , c2 text , c3 text, cs text static,
> PRIMARY KEY (c1, c2) );
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-1', 'x', 's1');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-2', 'x', 's2');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-3', 'x', 's3');
> cqlsh:test> insert into tt1 (c1, c2, c3, cs) VALUES ( '1', '1-4', 'x', 's4');
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> ----+-----+----+----
> 1 | 1-1 | s4 | x
> 1 | 1-2 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (4 rows)
> cqlsh:test> delete from tt1 WHERE c1='1' AND c2 = '1-2';
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> ----+-----+----+----
> 1 | 1-1 | s4 | x
> 1 | 1-3 | s4 | x
> 1 | 1-4 | s4 | x
> (3 rows)
> cqlsh:test> delete from tt1 WHERE c1='1' AND c2 = '1-4';
> cqlsh:test> select * from tt1;
> c1 | c2 | cs | c3
> ----+-----+----+----
> 1 | 1-1 | s4 | x
> 1 | 1-3 | s4 | x
> (2 rows)
> {code}
> Is this behavior bug or it's declared somewhere? Is it really good that
> deletion behavior is inconsistent?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
