[jira] [Created] (CASSANDRA-16069) Loss of functionality around null clustering when dropping compact storage

["Sylvain Lebresne (Jira)" <ji...@apache.org>]

Sylvain Lebresne created CASSANDRA-16069:
--------------------------------------------

             Summary: Loss of functionality around null clustering when dropping compact storage
                 Key: CASSANDRA-16069
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16069
             Project: Cassandra
          Issue Type: Bug
          Components: Legacy/CQL
            Reporter: Sylvain Lebresne


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:
{noformat}
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)
{noformat}
This is not allowed on non-compact tables however:
{noformat}
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"
{noformat}
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:
{noformat}
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"
{noformat}
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:
{noformat}
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)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org