[
https://issues.apache.org/jira/browse/CASSANDRA-10857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-10857:
------------------------------------
Reviewer: Sylvain Lebresne
Status: Patch Available (was: Open)
I've created a patch for the problem.
In order to facilitate uninterrupted upgrades, the new client option was added,
called {{NO_COMPACT}}. When this option is supplied, {{SELECT}}, {{UPDATE}},
{{DELETE}} and {{BATCH}} statements are functioning in "compatibility" mode,
which allows seeing the tables as if they were "regular" CQL tables. {{ALTER}}
and other DDL statements are not allowed in this compatibility mode as this
would create a potential conflict with flags and such schema changes do not
really feel safe. We could invest a lot of time into testing it and making it
possible, but since this feature is just for a transition period, it makes
sense to allow only the "safe" operations since after the compact flags are
dropped, any CQL operation will be possible on the table anyways. Since
technically we have only added a CQL option to the startup message, this sounds
like a change that does not require a protocol version bump (also considering
that this feature is 3.0/3.11 only).
For the problem with empty name in supercolumns, empty identifier was allowed
where applicable and an explicit check for it was added in all DDL statements.
|[3.0
patch|https://github.com/apache/cassandra/compare/trunk...ifesdjeen:10857-3.0]|[Python
Driver
Patch|https://github.com/datastax/python-driver/compare/master...ifesdjeen:10857]|[dtests|https://github.com/apache/cassandra-dtest/compare/master...ifesdjeen:10857]|
> Allow dropping COMPACT STORAGE flag from tables in 3.X
> ------------------------------------------------------
>
> Key: CASSANDRA-10857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10857
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Distributed Metadata
> Reporter: Aleksey Yeschenko
> Assignee: Alex Petrov
> Priority: Blocker
> Fix For: 3.0.x, 3.11.x
>
>
> Thrift allows users to define flexible mixed column families - where certain
> columns would have explicitly pre-defined names, potentially non-default
> validation types, and be indexed.
> Example:
> {code}
> create column family foo
> and default_validation_class = UTF8Type
> and column_metadata = [
> {column_name: bar, validation_class: Int32Type, index_type: KEYS},
> {column_name: baz, validation_class: UUIDType, index_type: KEYS}
> ];
> {code}
> Columns named {{bar}} and {{baz}} will be validated as {{Int32Type}} and
> {{UUIDType}}, respectively, and be indexed. Columns with any other name will
> be validated by {{UTF8Type}} and will not be indexed.
> With CASSANDRA-8099, {{bar}} and {{baz}} would be mapped to static columns
> internally. However, being {{WITH COMPACT STORAGE}}, the table will only
> expose {{bar}} and {{baz}} columns. Accessing any dynamic columns (any column
> not named {{bar}} and {{baz}}) right now requires going through Thrift.
> This is blocking Thrift -> CQL migration for users who have mixed
> dynamic/static column families. That said, it *shouldn't* be hard to allow
> users to drop the {{compact}} flag to expose the table as it is internally
> now, and be able to access all columns.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
