You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2017/11/03 09:18:00 UTC

[jira] [Commented] (CASSANDRA-10857) Allow dropping COMPACT STORAGE flag from tables in 3.X

    [ https://issues.apache.org/jira/browse/CASSANDRA-10857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237338#comment-16237338 ] 

Sylvain Lebresne commented on CASSANDRA-10857:
----------------------------------------------

Ok thanks. I'm +1 on the 3.0 and 3.11 patches, though I trust you'll run CI before committing.

Also +1 on the trunk minimal patch, except maybe that I believe the `COMPACT_STORAGE_DEPRECATION_MESSAGE` message would be primarily shown if something is trying to create a compact table in a mixed version cluster (the other case being the user trying to hack the schema tables manually, and while it's great we handle that properly, I'm less worried about the clarity of the message in that case because you are clearly messing around in the first place), so I'd add some kind of message to help the user understand why he's getting this. Something along the lines of "this can happen if you just created a COMPACT STORAGE table in a mixed-version cluster which is not supported". I'm fine having you do so on commit though. Same remark than above though, I'm assuming you made or will make sure CI looks good before committing. Lastly, we should also create a follow-up to clean up compact storage code internally.

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