[
https://issues.apache.org/jira/browse/CASSANDRA-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554505#comment-14554505
]
Sylvain Lebresne commented on CASSANDRA-9411:
---------------------------------------------
The problem is that on C* 2.0, {{SelectStatement}} aliases {{CFDefinition}}
instead of {{CFMetaData}}, the former being some post-processed version of
{{CFMetaData}} more suited to CQL. Except that when altering the table, while
{{CFMetadaData}} rebuilds a new updated {{CFDefinition}}, prepared statements
will still alias the old version and have some updated information. As a
result, we compute a broken index in {{ColumnGroupMap.Builder}} (the comparator
passed is the proper one, with collections infos, but the {{hasCollections}}
flag is outdated). The good fix is probably just to have {{SelectStatement}}
alias {{CFMetaData}} directly and call {{CFMetaData.getCfDef}} when it needs
the {{CFDefinition}} object. [~blerer] can you have a look at that soonish?
I'll note that this won't affect 2.1+, CASSANDRA-7910 or not.
> Bound statement executions fail after adding a collection-type column
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-9411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9411
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.13.
> OS X 10.9
> Reporter: Jorge Bay
> Assignee: Benjamin Lerer
> Fix For: 2.0.x
>
>
> After adding a collection-type column to an existing table, executions of
> statements that are already prepared result in server error (error code 0),
> with the error message {{java.lang.ArrayIndexOutOfBoundsException}}.
> To reproduce it.
> {code:java}
> session.execute("CREATE TABLE tbl1 (a text, b text, c text, PRIMARY KEY (a,
> b))");
> //prepare initially
> PreparedStatement ps = session.prepare("SELECT a, b, c FROM tbl1");
> //insert some data
> session.execute("INSERT INTO tbl1 (a, b, c) VALUES ('a1', 'b1', 'c1')");
> //Executes successfully as expected
> session.execute(ps.bind());
> //Add a column of a collection type
> session.execute("ALTER TABLE tbl1 ADD d set<text>");
> //All following executions fail
> session.execute(ps.bind());
> {code}
> Some notes:
> - This only occurs for SELECT with fields (not with SELECT *)
> - This only occurs with C* 2.0. Probably because CASSANDRA-7910 was applied
> for 2.1+
> - This only occurs if the column added is a collection type (list / set / map)
> - This occurs with all SELECT statements using that column family, that were
> already prepared.
> Repreparing it on all hosts fixes the issue, but for that, the user should
> normally restart existing application (even if the existing apps/apps
> versions don't handle this new field).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
