[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097242#comment-13097242
]
Jonathan Ellis edited comment on CASSANDRA-2474 at 9/5/11 6:50 PM:
-------------------------------------------------------------------
bq. composite/super columns won't originally play nice with SQL syntax because
it wasn't designed to query hierarchical data
That's exactly what "transposition" solves -- taking a horizontal slice and
"turning it sideways" into a resultset with the same set of columns.
We are NOT trying to solve a more generic hierarchical data problem -- all the
("leaf") data we select has to be at the same "level" in the hierarchy.
bq. if we have 10 subcolumns do I need to list them all using component syntax
You will if you are using the "dense" format. And let's be clear: this is NOT
the recommended way to do things, because it is fragile, as described above.
We want to support it [dense], but making it beautiful is not our goal. Sparse
encoding will be the recommended practice.
bq. it lacks scoping therefore on the big queries it will be hard to read, e.g.
"SELECT component1 AS tweet_id, component2 AS username, body, location, age,
value"
I don't understand, that seems perfectly readable to me.
bq. SELECT name AS (tweet_id, username | body | location | age), value AS body
This syntax is not viable for the reasons given in my previous comment. I'm
happy to entertain other alternatives to the component syntax but there's no
need to spend further time on this one.
was (Author: jbellis):
bq. composite/super columns won't originally play nice with SQL syntax
because it wasn't designed to query hierarchical data
That's exactly what "transposition" solves -- taking a horizontal slice and
"turning it sideways" into a resultset with the same set of columns.
We are NOT trying to solve a more generic hierarchical data problem -- all the
("leaf") data we select has to be at the same "level" in the hierarchy.
bq. if we have 10 subcolumns do I need to list them all using component syntax
You will if you are using the "dense" format. And let's be clear: this is NOT
the recommended way to do things, because it is fragile, as described above.
We want to support it, but making it beautiful is not our goal.
bq. it lacks scoping therefore on the big queries it will be hard to read, e.g.
"SELECT component1 AS tweet_id, component2 AS username, body, location, age,
value"
I don't understand, that seems perfectly readable to me.
bq. SELECT name AS (tweet_id, username | body | location | age), value AS body
This syntax is not viable for the reasons given in my previous comment. I'm
happy to entertain other alternatives to the component syntax but there's no
need to spend further time on this one.
> 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
