[
https://issues.apache.org/jira/browse/CASSANDRA-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945172#comment-13945172
]
Robbie Strickland edited comment on CASSANDRA-6915 at 3/24/14 2:42 PM:
-----------------------------------------------------------------------
It's the compound key (whether composite partition key or composite column)
case that makes this useful--and I would still argue really important. Yes you
can read the documentation to understand the mapping, but I think this remains
one of the most misunderstood concepts in CQL. I would argue that it's
important to understand the storage layer difference between PRIMARY KEY ((id,
timestamp), event) and PRIMARY KEY (id, timestamp, event), and that the best
way to see the difference is to visualize it. People still don't seem to get
the difference between partition keys and composite column names, and this
obviously has huge implications for what sorts of queries you can run and how
wide your rows will get.
Perhaps something along the lines of:
{code}
CREATE TABLE MyTable (
id uuid,
timestamp int,
event string,
details string,
userId string,
PRIMARY KEY (id, timestamp, event)
);
EXPLAIN MyTable;
Partition Key: id (uuid)
Columns:
timestamp:event:details (int:string:string)
timestamp:event:userId (int:string:string)
CREATE TABLE MyTable (
id uuid,
timestamp int,
event string,
details string,
userId string,
PRIMARY KEY ((id, timestamp), event)
);
EXPLAIN MyTable;
Partition Key: id:timestamp (uuid:int)
Columns:
event:details (string)
event:userId (string)
{code}
was (Author: rstrickland):
It's the compound key (whether composite partition key or composite column)
case that makes this useful--and I would still argue really important. Yes you
can read the documentation to understand the mapping, but I think this remains
one of the most misunderstood concepts in CQL. I would argue that it's
important to understand the storage layer difference between PRIMARY KEY ((id,
timestamp), event) and PRIMARY KEY (id, timestamp, event), and that the best
way to see the difference is to visualize it. People still don't seem to get
the difference between partition keys and composite column names, and this
obviously has huge implications for what sorts of queries you can run and how
wide your rows will get.
Perhaps something along the lines of:
CREATE TABLE MyTable (
id uuid,
timestamp int,
event string,
details string,
userId string,
PRIMARY KEY (id, timestamp, event)
);
EXPLAIN MyTable;
Partition Key: id (uuid)
Columns:
timestamp:event:details (int:string:string)
timestamp:event:userId (int:string:string)
CREATE TABLE MyTable (
id uuid,
timestamp int,
event string,
details string,
userId string,
PRIMARY KEY ((id, timestamp), event)
);
EXPLAIN MyTable;
Partition Key: id:timestamp (uuid:int)
Columns:
event:details (string)
event:userId (string)
> Show storage rows in cqlsh
> --------------------------
>
> Key: CASSANDRA-6915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6915
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Robbie Strickland
> Labels: cqlsh
>
> In Cassandra it's super important to understand how your CQL schema
> translates to the underlying storage rows. Right now the only way to see
> this is to create the schema in cqlsh, write some data, then query it using
> the CLI. Obviously we don't want to be encouraging people to use the CLI
> when it's supposed to be deprecated. So I'd like to see a function in cqlsh
> to do this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
