[jira] [Comment Edited] (CASSANDRA-4361) CQL3: allow definition with only a PK

["Ahmet AKYOL (JIRA)" <ji...@apache.org>]

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

Ahmet AKYOL edited comment on CASSANDRA-4361 at 7/7/12 4:22 PM:
----------------------------------------------------------------

"Definition with only a PK" is mostly for time series (wide row type) data and in that case "comparators" are the most critical configuration. CQL3 table definitions are mostly like SQL DDL but C* has its own way too.

AFAIK, we can't define "comparator" with cql3.  So, IMHO, this problem can be a sub-task to this issue. Or there can be a special syntax for this type of wide row tables:

{code}
CREATE TABLE ( id varchar PRIMARY KEY ) WITH WIDENING ORDER BY (uuid DESC);
{code}

Edit: I've just open an issue for this [CASSANDRA-4424|https://issues.apache.org/jira/browse/CASSANDRA-4424]
                
      was (Author: liqusha):
    "Definition with only a PK" is mostly for time series (wide row type) data and in that case "comparators" are the most critical configuration. CQL3 table definitions are mostly like SQL DDL but C* has its own way too.

AFAIK, we can't define "comparator" with cql3.  So, IMHO, this problem can be a sub-task to this issue. Or there can be a special syntax for this type of wide row tables:

{code}
CREATE TABLE ( id varchar PRIMARY KEY ) WITH WIDENING ORDER BY (uuid DESC);
{code}
                  
> CQL3: allow definition with only a PK
> -------------------------------------
>
>                 Key: CASSANDRA-4361
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4361
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: cql3
>             Fix For: 1.2
>
>
> Currently, in CQL3 and contrarily to SQL, one cannot define a table having only a PK but no other columns. Related to that, a CQL always needs at least one column outside of the PK to be inserted to exist. All that may force people to add 'fake' value that they don't really need.
> The goal of this ticket is to lift that limitation and allow table definition to have only a PK, and to have CQL rows exist even if only the PK has been inserted (in other words, to have CQL rows behave like SQL rows).
> Following CASSANDRA-4329, one way to do that with the sparse-composite encoding CQL3 uses would be to insert as marker of the CQL row presence a CQL column with an empty name (the underlying column name won't be empty though since it's a composite). The drawback though is that we will need to insert that marker with every insert to the CQL row (in other word, we'll add a slight overhead to the size of each write). The pros is that if we have such marker for the CQL row presence, we will be able to reoptimize back queries that select only a few columns (since following CASSANDRA-3982 we query all columns of a CQL row every time).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira