[ https://issues.apache.org/jira/browse/CASSANDRA-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098311#comment-17098311 ]
ZhaoYang commented on CASSANDRA-14699: -------------------------------------- The problem reported here can probably be mitigated by using proper timestamp via {{getPrimaryKeyIndexLiveness}} in {{CassandraIndex.indexerFor -> updateRow()}}. But there is a general issue in primary key secondary index which similar to what materialized view has, see CASSANDRA-11500: * the liveness of index entry is determined by primary key liveness info but liveness of base row is determined by primary key liveness info and its columns' liveness. > Querying using an indexed clustering column yields no result when a row has > been reinserted using an update following a delete > ------------------------------------------------------------------------------------------------------------------------------ > > Key: CASSANDRA-14699 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14699 > Project: Cassandra > Issue Type: Bug > Components: Feature/2i Index > Reporter: Jonathan Pellby > Priority: Normal > Labels: secondary_index > > If you have a secondary index on a clustering column in a table and you > delete a row from said table and then add it back again using an update, > querying for the row using the indexed clustering column does not yield any > result. > Dummy example to reproduce: > {code:java} > CREATE TABLE foo ( > a text, > b text, > c text, > d text, > e text, > PRIMARY KEY (a, b, c) > ); > CREATE INDEX ON foo (b); > CREATE INDEX ON foo (c); > CREATE INDEX ON foo (d); > CREATE INDEX ON foo (e); > update foo set d='4', e='5' where a='1' and b='2' and c='3'; > delete from foo where a='1' and b='2' and c='3'; > update foo set d='4', e='5' where a='1' and b='2' and c='3';{code} > Queries on the indexed clustering columns, e.g. > {code:java} > select * from foo where b='2'; > select * from foo where c='3';{code} > yield no result. Querying on the other (indexed and non-indexed) columns work > fine though. > Here's a comparison between the dump of the index for a clustering column and > the index of a non-clustering column. As far as I can tell, the row is > considered deleted in the index of b and c? > {code:java} > # Index for column c > /apache-cassandra-3.11.0/tools/bin # ./sstabledump > /data/data/foo/foo-875bbb60b1ab11e8b7406d2c86545d91/.foo_b_idx/mc-1-big-Data.db > [ > { > "partition" : { > "key" : [ "2" ], > "position" : 0 > }, > "rows" : [ > { > "type" : "row", > "position" : 34, > "clustering" : [ "31", "3" ], > "deletion_info" : { "marked_deleted" : "2018-09-06T08:05:10.093704Z", > "local_delete_time" : "2018-09-06T08:05:10Z" }, > "cells" : [ ] > } > ] > } > ] > # Index for d > /apache-cassandra-3.11.0/tools/bin # ./sstabledump > /data/data/foo/foo-875bbb60b1ab11e8b7406d2c86545d91/.foo_d_idx/mc-1-big-Data.db > [ > { > "partition" : { > "key" : [ "4" ], > "position" : 0 > }, > "rows" : [ > { > "type" : "row", > "position" : 32, > "clustering" : [ "31", "2", "3" ], > "liveness_info" : { "tstamp" : "2018-09-06T08:05:13.986242Z" }, > "cells" : [ ] > } > ] > } > ]{code} > This problem only occurs when the delete is followed by an update. If you > instead use an insert, e.g. > {code:java} > update foo set d='4', e='5' where a='1' and b='2' and c='3'; > delete from foo where a='1' and b='2' and c='3'; > insert into foo (a, b, c, d, e) VALUES ('1', '2', '3', '4', '5');{code} > all queries work and the dump for the indexed clustering columns look fine as > far as I can tell: > {code:java} > [ > { > "partition" : { > "key" : [ "2" ], > "position" : 0 > }, > "rows" : [ > { > "type" : "row", > "position" : 41, > "clustering" : [ "31", "3" ], > "liveness_info" : { "tstamp" : "2018-09-06T08:21:20.546530Z" }, > "deletion_info" : { "marked_deleted" : "2018-09-06T08:21:11.027171Z", > "local_delete_time" : "2018-09-06T08:21:11Z" }, > "cells" : [ ] > } > ] > } > ]{code} > I was able to reproduce this problem in both 3.11.0 and 3.11.3. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org