When you alter a table the Cassandra server invalidates the prepared statements it is holding, so when clients (like your own) execute the prepared statement the server informs the client it needs to be re-prepared and the client does it automatically. If this isn’t working for you then you should comment with your use case on the jira issue.
From: joseph gao [mailto:gaojf.bok...@gmail.com] Sent: Tuesday, June 16, 2015 10:31 AM To: user@cassandra.apache.org Subject: Re: PrepareStatement problem But I'm using 2.1.6, I still get this bug. So, I should discard that PrepareStatement when I get the alter table message? How can I get and deal that message? 2015-06-15 16:45 GMT+08:00 Peer, Oded <oded.p...@rsa.com<mailto:oded.p...@rsa.com>>: This only applies to “select *” queries where you don’t specify the column names. There is a reported bug and fixed in 2.1.3. See https://issues.apache.org/jira/browse/CASSANDRA-7910 From: joseph gao [mailto:gaojf.bok...@gmail.com<mailto:gaojf.bok...@gmail.com>] Sent: Monday, June 15, 2015 10:52 AM To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: PrepareStatement problem hi, all I'm using PrepareStatement. If I prepare a sql everytime I use, cassandra will give me a warning tell me NOT PREPARE EVERYTIME. So I Cache the PrepareStatement locally . But when other client change the table's schema, like, add a new Column, If I still use the former Cached PrepareStatement, the metadata will dismatch the data. The metadata tells n column, and the data tells n+1 column. So what should I do to avoid this problem? -- ------ Joseph Gao PhoneNum:15210513582 QQ: 409343351 -- ------ Joseph Gao PhoneNum:15210513582 QQ: 409343351
