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)
