[
https://issues.apache.org/jira/browse/CASSANDRA-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408229#comment-13408229
]
Ahmet AKYOL commented on CASSANDRA-4361:
----------------------------------------
"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