[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096842#comment-13096842
]
Pavel Yaskevich edited comment on CASSANDRA-2474 at 9/4/11 9:57 AM:
--------------------------------------------------------------------
bq. Remember that the ideal for CQL is to have "SELECT x, y, z" and get back
exactly columns x, y, and z.
composite/super columns won't originally play nice with SQL syntax because it
wasn't designed to query hierarchical data.
Few problems I have with componentX syntax:
- if we have 10 subcolumns do I need to list them all using component syntax
(which would be totally unreadable)?
- it lacks scoping therefore on the big queries it will be hard to read
e.g.
{noformat}
SELECT component1 AS tweet_id, component2 AS username, body, location, age,
value AS body
{noformat}
- will potentially be hard to put into grammar because it can have ambiguous
rules again because lack of scoping
- why should we force users to actually give each component a number?
And I don't get why do you think that (..,..,..) is a "rocket science" syntax:
If we presume that user should be familiar with composite type columns before
start using the syntax then he will know what does each section (separated by
",") mean:
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
{noformat}
means that we have three sections as column name which we are aliasing to
tweet_id, username, location
{noformat}
SELECT name AS (tweet_id, username | body | location | age), value AS body
{noformat}
means that we have two components in the name: first one - tweet_id, and second
component that has multiple meanings but we only want to get username, body,
location
{noformat}
SELECT name AS (tweet_id, *), value AS body
{noformat}
means that we still have two components in the column name but we don't care
what holds component #2 and we expect result set to return all of the possible
values.
was (Author: xedin):
bq. Remember that the ideal for CQL is to have "SELECT x, y, z" and get
back exactly columns x, y, and z.
composite/super columns won't originally play nice with SQL syntax because it
wasn't designed to query hierarchical data.
Few problems I have with componentX syntax:
- if we have 10 subcolumns do I need to list them all using component syntax
(which would be totally unreadable)?
- it lacks scoping therefore on the big queries it will be hard to read
e.g.
{noformat}
SELECT component1 AS tweet_id, component2 AS username, body, location,
age, value AS body
{noformat}
- will potentially be hard to put into grammar because it can have ambiguous
rules again because lack of scoping
- why should we force users to actually give each component a number?
And I don't get why do you think that (..,..,..) is a "rocket science" syntax:
If we presume that user should be familiar with composite type columns before
start using the syntax then he will know what does each section (separated by
",") mean:
{noformat}
SELECT name AS (tweet_id, username, location), value AS body
{noformat}
means that we have three sections as column name which we are aliasing to
tweet_id, username, location
{noformat}
SELECT name AS (tweet_id, username | body | location | age), value AS body
{noformat}
means that we have two components in the name: first one - tweet_id, and second
component that has multiple meanings but we only want to get username, body,
location
{noformat}
SELECT name AS (tweet_id, *), value AS body
means that we still have two components in the column name but we don't care
what holds component #2 and we expect result set to return all of the possible
values.
> 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
