[ https://issues.apache.org/jira/browse/CASSANDRA-16069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183171#comment-17183171 ]
Romain Hardouin commented on CASSANDRA-16069: --------------------------------------------- IMHO Solution #3 seems the safest solution if it's clearly documented. Dropping COMPACT STORAGE is not something users do in production without testing. They must ensure that apps/services work without errors. If a service relies on this brittle "feature", it will still be able to access data using a slice query. There is no data unavailability, which is the most important thing I think. On top of that, it's not a sneaky change with a silent error. INSERT and UPDATE will throw InvalidRequest that should appear during tests. > 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