[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096808#comment-13096808
]
Jonathan Ellis commented on CASSANDRA-2474:
-------------------------------------------
Remember that the ideal for CQL is to have "SELECT x, y, z" and get back
exactly columns x, y, and z. The farther we get from that the more conceptual
debt we incur.
bq. SELECT name AS (tweet_id, username, location), value AS body
This is probably acceptable because many people are familiar with destructuring
assignment and the intuition from that is accurate here: you have a single
[cassandra] column, that gets destructured into multiple [resultset] columns.
bq. SELECT name as (tweet_id, username|body) ....
But this doesn't match intuition for either SQL, or destructuring assignment.
Because what you're doing is actually turning multiple cassandra columns, into
a single row. I think the component syntax does a better job of describing
this -- you use "componentX" in the composite tree until you get to the
"parent" of the named fields, and then you can use those names directly.
I think we should go with the component syntax for now (since it can handle
both sparse and dense) and consider adding the destructuring syntax for dense
encodings later.
> CQL support for compound columns
> --------------------------------
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Eric Evans
> Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 1.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> For the most part, this boils down to supporting the specification of
> compound column names (the CQL syntax is colon-delimted terms), and then
> teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
