[
https://issues.apache.org/jira/browse/CASSANDRA-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15555025#comment-15555025
]
Alex Petrov edited comment on CASSANDRA-12373 at 10/12/16 9:31 AM:
-------------------------------------------------------------------
I've started collecting information on what needs to be done. I just want to
clarify the behaviour first:
We would like to change the way schema and the resultset are currently
represented (instead of the {{"" map<key_type, value_type>}} to two actual
columns: {{column<number>}} (depending on the current clustering key size) and
{{value}}, just as it was presented in example in [CASSANDRA-12335], although
preserve their internal representation (internally, map type will still be used
for storage).
In CQL terms
{code}
CREATE TABLE tbl (
key ascii,
column1 ascii,
"" map<int, ascii>,
PRIMARY KEY (key, column1))
AND COMPACT STORAGE
{code}
would become
{code}
CREATE TABLE tbl (
key ascii,
column1 ascii,
column2 int,
value ascii,
PRIMARY KEY (key, column1))
AND COMPACT STORAGE
{code}
(note that {{column2}} is not clustering as [~slebresne] described in comment).
And this kind of special-casing will be valid for both read and write paths.
was (Author: ifesdjeen):
I've started collecting information on what needs to be done. I just want to
clarify the behaviour first:
We would like to change the way schema and the resultset are currently
represented (instead of the {{"" map<key_type, value_type>}} to two actual
columns: {{column<number>}} (depending on the current clustering key size) and
{{value}}, just as it was presented in example in [CASSANDRA-12335].
In CQL terms
{code}
CREATE TABLE tbl (
key ascii,
column1 ascii,
"" map<int, ascii>,
PRIMARY KEY (key, column1))
AND COMPACT STORAGE
{code}
would become
{code}
CREATE TABLE tbl (
key ascii,
column1 ascii,
column2 int,
value ascii,
PRIMARY KEY (key, column1))
AND COMPACT STORAGE
{code}
(note that {{column2}} is not clustering as [~slebresne] described in comment).
And this kind of special-casing will be valid for both read and write paths.
> 3.0 breaks CQL compatibility with super columns families
> --------------------------------------------------------
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Reporter: Sylvain Lebresne
> Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column
> compatibility.
> The details and a proposed solution can be found in the comments of
> CASSANDRA-12335 but the crux of the issue is that super column famillies show
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward
> compatibilty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
