[jira] [Commented] (CASSANDRA-9166) Prepared statements using functions in collection literals aren't invalidated when functions are dropped

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

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

Aleksey Yeschenko commented on CASSANDRA-9166:
----------------------------------------------

Good catch. Committed to trunk as {{d9836e0efe66c0cc0e33f32b605f6920893fa7a5}}. Made a small change to {{QueryProcessor.removeInvalidPreparedStatementsForFunction()}} on commit, to make the logic a bit more obvious, otherwise committed as is. Thanks.

> Prepared statements using functions in collection literals aren't invalidated when functions are dropped
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9166
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9166
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>              Labels: cql, functions
>             Fix For: 3.x
>
>
> When a function is dropped, any prepared statements which reference it need to be removed from the prepared statement cache. 
> The default implementation of {{Term#usesFunction}} in {{Term.NonTerminal}} is not overriden in all the places it should be. The {{DelayedValue}} classes in {{Lists}}, {{Sets}}, {{Maps}} and {{Tuples}} may all make use of function calls.
> {code}
> CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
> CREATE TABLE ks.t1 (k int PRIMARY KEY, v list<int>);
> CREATE FUNCTION ks.echo_int(input int) RETURNS int LANGUAGE javascript AS 'input';
> {code}
> a prepared statement of the form:
> {code}
> INSERT INTO ks.t1 (k, v) VALUES (?, [ks.echo_int(?)]);
> {code}
> should be dropped when {{ks.echo_int(int)}} is, but currently that isn't the case.



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