[
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: [email protected]
For additional commands, e-mail: [email protected]
