Fix Version/s: None
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
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