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

Loss of functionality around null clustering when dropping compact storage

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Normal
    • Resolution: Unresolved
    • None
    • Legacy/CQL
    • None
    • Correctness - API / Semantic Definition
    • Low
    • Normal
    • Code Inspection
    • All
    • None

    Description

      For backward compatibility reasons[1], it is allowed to insert rows where some of the clustering columns are null for compact tables. That support is a tad limited/inconsistent[2] but essentially you can do:

      cqlsh:ks> CREATE TABLE t (k int, c1 int, c2 int, v int, PRIMARY KEY (k, c1, c2)) WITH COMPACT STORAGE;
      cqlsh:ks> INSERT INTO t(k, c1, v) VALUES (1, 1, 1);
      cqlsh:ks> SELECT * FROM t;
      
       k | c1 | c2   | v
      ---+----+------+---
       1 |  1 | null | 1
      
      (1 rows)
      cqlsh:ks> UPDATE t SET v = 2 WHERE k = 1 AND c1 = 1;
      cqlsh:ks> SELECT * FROM t;
      
       k | c1 | c2   | v
      ---+----+------+---
       1 |  1 | null | 2
      
      (1 rows)
      

      This is not allowed on non-compact tables however:

      cqlsh:ks> CREATE TABLE t2 (k int, c1 int, c2 int, v int, PRIMARY KEY (k, c1, c2));
      cqlsh:ks> INSERT INTO t2(k, c1, v) VALUES (1, 1, 1);
      InvalidRequest: Error from server: code=2200 [Invalid query] message="Some clustering keys are missing: c2"
      cqlsh:ks> UPDATE t2 SET v = 2 WHERE k = 1 AND c1 = 1;
      InvalidRequest: Error from server: code=2200 [Invalid query] message="Some clustering keys are missing: c2"
      

      Which means that a user with a compact table that rely on this will not be able to use DROP COMPACT STORAGE.

      Which is a problem for the 4.0 upgrade story. Problem to which we need an answer.

       


      [1]: the underlying CompositeType used by such tables allows to provide only a prefix of components, so thrift users could have used such functionality. We thus had to support it in CQL, or those users wouldn't have been able to upgrade to CQL easily.

      [2]: building on the example above, the value for c2 is essentially null, yet none of the following is currently allowed:

      cqlsh:ks> INSERT INTO t(k, c1, c2, v) VALUES (1, 1, null, 1);
      InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid null value in condition for column c2"
      cqlsh:ks> UPDATE t SET v = 2 WHERE k = 1 AND c1 = 1 AND c2 = null;
      InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid null value in condition for column c2"
      cqlsh:ks> SELECT * FROM c WHERE k = 1 AND c1 = 1 AND c2 = null;
      InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid null value in condition for column c2"
      

      Not only is that unintuitive/inconsistent, but the SELECT one means there is no way to select only the row. You can skip specifying c2 in the SELECT, but this become a slice selection essentially, as shown below:

      cqlsh:ks> INSERT INTO ct(k, c1, c2, v) VALUES (1, 1, 1, 1);
      cqlsh:ks> SELECT * FROM ct WHERE k = 1 AND c1 = 1;
      
       k | c1 | c2   | v
      ---+----+------+---
       1 |  1 | null | 1
       1 |  1 |    1 | 1
      
      (2 rows)
      

      Attachments

        Activity

          People

            Unassigned Unassigned
            slebresne Sylvain Lebresne
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: