[jira] [Comment Edited] (CASSANDRA-6915) Show storage rows in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (CASSANDRA-6915) Show storage rows in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945172#comment-13945172
]
Robbie Strickland edited comment on CASSANDRA-6915 at 3/24/14 2:44 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:string)
event:userId (string: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:
{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}
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)
