Amichai Rothman created CASSANDRA-8153: ------------------------------------------
Summary: PreparedStatements broken when column family is recreated Key: CASSANDRA-8153 URL: https://issues.apache.org/jira/browse/CASSANDRA-8153 Project: Cassandra Issue Type: Bug Components: Core Reporter: Amichai Rothman The scenario: 1. Create a PreparedStatement which references some column family. 2. Cache the PreparedStatement instance (afaik this is standard practice). 3. Execute the statement - it works. 4. Drop the column family. 5. Recreate the column family. 6. Execute the statement - it fails (and will forever fail). This scenario worked properly on earlier versions. As of 2.1.0, it's broken - the prepared statement seems to be bound to the deleted column family and is not re-bound to the new one. At a glance, this may be caused by CASSANDRA-5202. Workaround: client code must invalidate its PreparedStatement cache when a DROP query is executed (on column family, keyspace, and possibly others). The best fix would be to keep the cf_ids as an internal implementation detail, and make sure the query (which references the column family by name) continues to work by re-resolving the cf to the new one, rather than breaking client code due to this implementation detail. An alternative fix would be to document this code-breaking change and instruct clients to implement the workaround in their prepared statement caches. I'm not familiar with any of these internals (other than the several hours I spent trying to figure out why my unit tests started failing), so if anything in this report is incorrect, feel free to correct it :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)