cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families
Date Wed, 12 Oct 2016 10:57:20 GMT

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

Mime
View raw message