[
https://issues.apache.org/jira/browse/CASSANDRA-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita resolved CASSANDRA-8153.
---------------------------------------
Resolution: Duplicate
This should be fixed in 2.1.1.
> 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)
