[ https://issues.apache.org/jira/browse/CASSANDRA-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Eriksson updated CASSANDRA-15811: ---------------------------------------- Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Normal Component/s: Cluster/Schema Discovered By: Adhoc Test Fix Version/s: 3.11.x 3.0.x Severity: Normal Status: Open (was: Triage Needed) > Improve DROP COMPACT STORAGE > ---------------------------- > > Key: CASSANDRA-15811 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15811 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema > Reporter: Alex Petrov > Assignee: Marcus Eriksson > Priority: Normal > Fix For: 3.0.x, 3.11.x > > > DROP COMPACT STORAGE was introduced in CASSANDRA-10857 as one of the steps to > deprecate Thrift. However, current semantics of dropping compact storage > flags from tables reveal several columns that are usually empty (colum1 and > value in non-dense case, value for dense columns, and a column with an empty > name for super column families). Showing these columns can confuse > application developers, especially ones that have never used thrift and/or > made writes that assumed presence of those fields, and used compact storage > in 3.x because is has “compact” in the name. > There’s not much we can do in a super column family case, especially > considering there’s no way to create a supercolumn family using CQL, but we > can improve dense and non-dense cases. We can scan stables and make sure > there are no signs of thrift writes in them, and if all sstables conform to > this rule, we can not only drop the flag, but also drop columns that are > supposed to be hidden. However, this is both not very user-friendly, and is > probably not worth development effort. > An alternative to scanning is to add {{FORCE DROP COMPACT}} syntax (or > something similar) that would just drop columns unconditionally. It is likely > that people who were using compact storage with thrift know they were doing > that, so they'll usually use "regular" {{DROP COMPACT}}, withouot force, that > will simply reveal the columns as it does right now. > Since for fixing CASSANDRA-15778, and to allow EmptyType column to actually > have data[*] we had to remove empty type validation, properly handling > compact storage starts making more sense, but we’ll solve it through not > having columns, hence not caring about values instead, or keeping values > _and_ data, not requiring validation in this case. EmptyType field will have > to be handled differently though. > [*] as it is possible to end up with sstables upgraded from 2.x or written in > 3.x before CASSANDRA-15373, which means not every 2.x upgraded or 3.x cluster > is guaranteed to have empty values in this column, and this behaviour, even > if undesired, might be used by people. > Open question is: CASSANDRA-15373 adds validation to EmptyType that disallows > any non-empty value to be written to it, but we already allow creating table > via CQL, and still write data into it with thrift. It seems to have been > unintended, but it might have become a feature people rely on. If we simply > back port 15373 to 2.2 and 2.1, we’ll change and break behaviour. Given > no-one complained in 3.0 and 3.11, this assumption is unlikely though. -- 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