[ https://issues.apache.org/jira/browse/CASSANDRA-16069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-16069: ----------------------------------------- Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Definition(13162) Complexity: Normal Discovered By: Code Inspection Severity: Low Status: Open (was: Triage Needed) > 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 > Priority: Normal > > 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