Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-8153

PreparedStatements broken when column family is recreated



    • Bug
    • Status: Resolved
    • Normal
    • Resolution: Duplicate
    • None
    • None
    • None
    • Normal


      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


        Issue Links



              Unassigned Unassigned
              amichai Amichai Rothman
              0 Vote for this issue
              1 Start watching this issue