[ 
https://issues.apache.org/jira/browse/CASSANDRA-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090690#comment-17090690
 ] 

Ricardo Boccato Alves edited comment on CASSANDRA-14699 at 4/23/20, 3:20 PM:
-----------------------------------------------------------------------------

Same thing is happening when using partition keys (tested on 3.11.4, 3.11.5 and 
3.11.6).

With this setup:
  
{code:java}
CREATE TABLE bar (
  a text,
  b text,
  c text,
  PRIMARY KEY ((a,b))
);

CREATE INDEX ON bar (a);

update bar set c = '3' where a = '1' and b = '2';
delete from bar where a = '1' and b = '2';
update bar set c = '3' where a = '1' and b = '2';{code}
 
  The result is:
{code:java}
cqlsh:bla> select * from bar;
 a | b | c
---+---+---
 1 | 2 | 3
(1 rows)

cqlsh:bla> select * from bar where a = '1' and b = '2';
 a | b | c
---+---+---
 1 | 2 | 3
(1 rows)

cqlsh:bla> select * from bar where a = '1';
 a | b | c
---+---+---
(0 rows)
{code}
If I change the second update to an insert, everything works fine.


was (Author: boccato):
Same thing is happening when using partition keys (tested on 3.11.4, 3.11.5 and 
3.11.6).

With this setup:
 
{code:java}
CREATE TABLE bar (
  a text,
  b text,
  c text,
  PRIMARY KEY ((a,b))
);

CREATE INDEX ON bar (a);

update bar set c = '3' where a = '1' and b = '2';
delete from bar where a = '1' and b = '2';
update bar set c = '3' where a = '1' and b = '2';{code}
 
 The result is:
{code:java}
cqlsh:bla> select * from bar ; a | b | c
---+---+---
 1 | 2 | 3
(1 rows)

cqlsh:bla> select * from bar where a = '1' and b = '2'; a | b | c
---+---+---
 1 | 2 | 3
(1 rows)

cqlsh:bla> select * from bar where a = '1'; a | b | c
---+---+---
(0 rows)
{code}
If I change the second update to an insert, everything works fine.

> 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

Reply via email to