[ https://issues.apache.org/jira/browse/CASSANDRA-14071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275925#comment-16275925 ]
ZhaoYang commented on CASSANDRA-14071: -------------------------------------- Thanks for the feedback. bq. The approach looks good to me but even though this looks safe I think we should restrict this new resolution rule only to pk liveness info of views to ensure no other code path can be affected by this since this is a pretty critical path. What do you think? Current TTL in insert/update request is at most 20 yrs defined in Attributes.java, but there is no TTL limit for table default_time_to_live. I think using a very large default_time_to_live is not reasonable because {{TTL + nowInSeconds}} can cause int32 overflow. I added an validation logic in {{TableParams}} to make sure default_time_to_live will never be {{Integer.MAX_VALUE}} which is reserved for MV.. Or do you think adding a method param, eg {{isView}}, to {{LivenessInfo.supersedes()}} is safer? bq. Also, besides the case with default ttl, this also affects overwrites with ttl right? Can you add a test with this case as well? Make sense, I have updated the test with user-provided TTL > Materialized view on table with TTL issue > ----------------------------------------- > > Key: CASSANDRA-14071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14071 > Project: Cassandra > Issue Type: Bug > Components: Coordination, Materialized Views > Environment: Cassandra 3 > Reporter: Silviu Butnariu > Assignee: ZhaoYang > Labels: correctness > > Materialized views that cluster by a column that is not part of table's PK > and are created from tables that have *default_time_to_live* seems to > malfunction. > Having this table > {code:java} > CREATE TABLE sbutnariu.test_bug ( > field1 smallint, > field2 smallint, > date timestamp, > PRIMARY KEY ((field1), field2) > ) WITH default_time_to_live = 1000; > {code} > and the materialized view > {code:java} > CREATE MATERIALIZED VIEW sbutnariu.test_bug_by_date AS SELECT * FROM > sbutnariu.test_bug WHERE field1 IS NOT NULL AND field2 IS NOT NULL AND date > IS NOT NULL PRIMARY KEY ((field1), date, field2) WITH CLUSTERING ORDER BY > (date desc, field2 asc); > {code} > After inserting 3 rows with same PK (should upsert), the materialized view > will have 3 rows. > {code:java} > insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, > toTimestamp(now())); > insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, > toTimestamp(now())); > insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, > toTimestamp(now())); > select * from sbutnariu.test_bug; /*1 row*/ > select * from sbutnariu.test_bug_by_date;/*3 rows*/ > {code} > If I remove the ttl and try again, it works as expected: > {code:java} > truncate sbutnariu.test_bug; > alter table sbutnariu.test_bug with default_time_to_live = 0; > select * from sbutnariu.test_bug; /*1 row*/ > select * from sbutnariu.test_bug_by_date;/*1 row*/ > {code} > I've tested on versions 3.0.14 and 3.0.15. The bug was introduced in 3.0.15, > as in 3.0.14 it works as expected. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org