cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8353) Prepared statement doesn't revalidate after table schema changes
Date Fri, 21 Nov 2014 12:31:33 GMT


Aleksey Yeschenko commented on CASSANDRA-8353:

Do you mean 'invalidate', not 'revalidate'?

We can't just silently change things under the hood, because the drivers would have the resultset
metadata without `value2`.

What we can (and probably should) do is to extend CASSANDRA-7566 and invalidate the statements
like this once schema changes like this happen (added/altered/dropped column or dropped index).

> Prepared statement doesn't revalidate after table schema changes
> ----------------------------------------------------------------
>                 Key: CASSANDRA-8353
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.1.2
>            Reporter: MichaƂ Jaszczyk
> Having simple table:
> {code}
> CREATE TABLE test1 (
>   key TEXT,
>   value TEXT,
>   PRIMARY KEY (key)
> );
> {code}
> I prepare following statement:
> {code}
> SELECT * FROM test1;
> {code}
> I run queries based on the statement which returns expected results.
> Then I update schema definition like this:
> {code}
> ALTER TABLE test1 ADD value2 TEXT;
> {code}
> I populate the "value2" values and use the same statement again. The results returned
by the same query don't include "value2". I'm sure it is not cached in the driver/application
because I was starting new process after changing schema.
> It looks to me like a bug. Please correct me if it works like this on purpose.
> I'm using ruby cql driver but I believe it is not related.

This message was sent by Atlassian JIRA

View raw message