[ 
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 10:56 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 return results in form of  

{code}
 key          | column1 | column2 | value  |
--------------+---------+---------+--------+
 key1         | val1    | 1       | value1 |
 key1         | val1    | 2       | value2 |
 key1         | val1    | 3       | value3 |
 key1         | val2    | 1       | value1 |
 key1         | val2    | 2       | value2 |
 key1         | val2    | 3       | value3 |
{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], 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.

> 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)

Reply via email to