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

Sylvain Lebresne commented on CASSANDRA-10758:
----------------------------------------------

bq. Had you got something more in mind?

Not particularly. My sentence should really be read "I'm tired of looking at 
fixing stuff that are not directly related to the issue" and I hadn't really 
looked at how to fix it at all tbh. But the fix does is trivial so good and +1 
on the patch, modulo clean CI (which doesn't seem to have been started yet).

> Dropping an index does not invalidate prepared statements anymore
> -----------------------------------------------------------------
>
>                 Key: CASSANDRA-10758
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10758
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Sylvain Lebresne
>            Assignee: Sam Tunnicliffe
>              Labels: secondary_index
>             Fix For: 3.0.1, 3.1
>
>
> When we drop an index, we should invalidate ({{SELECT}}) statements on the 
> base table as those may involve the index (and, for instance, validating an 
> index exists is done a preparation time in {{SELECT}}, so a {{SELECT}} does 
> potentially become invalid if an index is dropped). As far as I can tell, 
> this is properly done in pre-3.0, because {{CFMetaData.apply}} will return 
> {{true}} which will trigger the statements invalidations. And that is 
> because, before 3.0, index definitions are part of the {{ColumnDefinition}} 
> of the base table and thus dropping an index is (rightfullly in a way) 
> considered by {{CFMetaData}} as a change to the table columns. In 3.0 
> however, as indexes has been moved out of {{ColumnDefinition}}, 
> {{CFMetaData.apply}} returns {{false}} in that case and statements are not 
> invalidated.
> I'll note that the changes to {{CQLTester}} done in CASSANDRA-10631 actually 
> expose this problem (but indirectly so we should create a purpose built tests 
> for this).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to