cassandra-commits mailing list archives

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

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

Sylvain Lebresne commented on CASSANDRA-12373:
----------------------------------------------

bq. We would like to change the way schema and the resultset are currently represented

Actually, we don't want to touch the schema. That is, to be precise, this ticket shouldn't
change how anything is stored internally, and shouldn't thus change the schema tables. This
does mean that fixing the output of {{DESCRIBE}} is actually not a direct part of this ticket,
as I believe it's implemented by the python nowadays. We would however encourage drivers to
special case super column familes too so that they expose {{tbl}} table of your example as:
{noformat}
CREATE TABLE tbl (
        key ascii,
        column1 ascii,
        column2 int,
        value ascii,
        PRIMARY KEY (key, column1, column2)
) WITH COMPACT STORAGE;
{noformat}
and that's indeed how we want the table to behave.
would return results in form of

bq. would return results in form of

Yes, that's what we want. But this goes beyond just result-sets, we want the table to behave
exactly as if it was the definition from above, namely that we'll allow queries like
{noformat}
INSERT INTO tbl (key, column1, column2, value) VALUES (...);
SELECT value FROM tbl WHERE key = 'key1' AND column1 = 'val1' AND column2 = 2;
{noformat}
but we will *not* allow
{noformat}
INSERT INTO tbl (key, column1, "") VALUES (....);
SELECT "" FROM tbl WHERE key = 'key1' AND column1 = 'val1';
{noformat}

In general though, the best description of what we want this ticket to do is that any CQL
query on a super column table should behave in 3.0/3.x _exactly_ as it behaved in 2.x. Which
highlight the fact that we have no CQL tests for super columns, and a first step could be
to write a decent coverage and test it on 2.x. And then we get it to work on 3.0/3.x.

I'll note that as I said in CASSANDRA-12335, this means we'll probably need to intercept INSERT/UPDATE
and SELECT (raw) statements on super column table early and basically rewrite them to match
the internal representation, plus post-processing result sets. It would be really nice if
we could keep all that code reasonably encapsulated too. 

> 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