[
https://issues.apache.org/jira/browse/CASSANDRA-11820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288575#comment-15288575
]
Sylvain Lebresne commented on CASSANDRA-11820:
----------------------------------------------
Let's double check it's the actual problem though before disallowing stuff
blindly, because that kind of things is supposed to be handled (which doesn't
mean it isn't broken, but I want to understand why). Also, disallowing things
that previously weren't is strictly speaking a breaking change.
I'll note however that the description is low in details: if this was done on a
multi-node cluster without waiting for schema agreement between the {{ALTER}}
and the {{SELECT}}, then yes, that could be the problem as the storage engine
does assume you will wait for the schema change to be propagated before
querying.
> Altering a column's type causes EOF
> -----------------------------------
>
> Key: CASSANDRA-11820
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11820
> Project: Cassandra
> Issue Type: Bug
> Reporter: Carl Yeksigian
> Fix For: 3.0.x, 3.x
>
>
> While working on CASSANDRA-10309, I was testing altering columns' types. This
> series of operations fails:
> {code}
> CREATE TABLE test (a int PRIMARY KEY, b int)
> INSERT INTO test (a, b) VALUES (1, 1)
> ALTER TABLE test ALTER b TYPE BLOB
> SELECT * FROM test WHERE a = 1
> {code}
> Tried this on 3.0 and trunk, both fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
