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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
