You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Eriksson (Jira)" <ji...@apache.org> on 2020/06/22 07:41:00 UTC

[jira] [Updated] (CASSANDRA-15811) Improve DROP COMPACT STORAGE

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