Hello, While testing 3.0.15, we noticed that some materialized views started showing rows that shouldn't exist, as multiple rows in the view map to a single row in the base table.
I've pasted the table structure below, but essentially there's a base table "((pk1,pk2,pk3),ck1),col1" and MV "((pk1,pk2,pk3),col1,ck1)". This means that if col1 changes, we expect a delete and insert on the MV. And yet this happens: > select col1, ck1, dateof(col1) FROM view_1 where pk1='abc' and pk2='123' and pk3='def'; col1 | ck1 | system.dateof(col1) --------------------------------------+--------------------------------------+--------------------------------- 7bd437d9-bccc-11e7-9748-40749b41c1e0 | 295eae9b-d544-4064-8dbc-0c56772759f3 | 2017-10-29 17:13:29.494000+0000 df39e364-bed3-11e7-8a3d-953c29bf01ff | 295eae9b-d544-4064-8dbc-0c56772759f3 | 2017-11-01 07:11:25.057000+0000 928980ae-bed5-11e7-8b41-6e709b16923d | 295eae9b-d544-4064-8dbc-0c56772759f3 | 2017-11-01 07:23:35.388000+0000 # Only relevant rows are shown > select col1,writetime(col1),dateof(col1) from table_1 where pk1='abc' and pk2='123' and pk3='def' and ck1='295eae9b-d544-4064-8dbc-0c56772759f3'; col1 | writetime(col1) | system.dateof(col1) --------------------------------------+-------------------------+--------------------------------- 928980ae-bed5-11e7-8b41-6e709b16923d | 1509728864328000 | 2017-11-01 07:23:35.388000+0000 It's not supposed to be possible, and yet there are three rows that all map onto the same primary key in the base table. The cluster was upgraded on 2017-10-31, so the first row could *maybe* be explained by CASSANDRA-11500, but the second row can't. The third row is the one we expect to be there. Is this a new regression in 3.0.15? Is anyone else experiencing this, or should I file a ticket? Thanks, Tom ------- Full structure: --------- CREATE TABLE the_keyspace.table_1 ( pk1 ascii, pk2 ascii, pk3 ascii, ck1 ascii, col1 timeuuid, PRIMARY KEY ((pk1, pk2, pk3), ck1) ) WITH CLUSTERING ORDER BY (ck1 ASC) AND bloom_filter_fp_chance = 0.1 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; CREATE MATERIALIZED VIEW the_keyspace.view_1 AS SELECT * FROM the_keyspace.table_1 WHERE pk1 IS NOT NULL AND pk2 IS NOT NULL AND pk3 IS NOT NULL AND col1 IS NOT NULL AND ck1 IS NOT NULL PRIMARY KEY ((pk1, pk2, pk3), col1, ck1) WITH CLUSTERING ORDER BY (col1 ASC, ck1 ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; Tom van der Woerdt Site Reliability Engineer Booking.com B.V. Vijzelstraat 66-80 Amsterdam 1017HL Netherlands [image: Booking.com] <http://www.booking.com/> The world's #1 accommodation site 43 languages, 204+ offices worldwide, 118,000+ global destinations, 1,500,000+ room nights booked every day No booking fees, best price always guaranteed Subsidiary of the Priceline Group (NASDAQ: PCLN)