[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171208#comment-13171208
]
Jonathan Ellis commented on CASSANDRA-2474:
-------------------------------------------
Thinking out loud:
- We need to support adding "new" subcolumns in the "sparse" case but it
doesn't make sense to have wildly different types of data in the same CF (an
antipattern). So it's probably okay to have use some kind of predeclaration
like {{CREATE TRANSPOSED TABLE}} to simplify querying.
- If we do use that approach do we want to continue to require FROM
table:TRANSPOSED syntax in the SELECT?
- {{SELECT x, y FROM foo:key}} syntax really gives the right "you're selecting
a resultset from this row" flavor. But, it doesn't allow composing with the
normal WHERE predicates, especially {{key > foo}} and {{key IN (...)}}, i.e.
range scans and multigets. I can live without multigets, although it would be
a loss of functionality since the Thrift API supports slice multiget, but we
can't live without range scans (for Hadoop, since I want to move CFIF to CQL)
- We need to support combinations of "sparse" and "dense." But at most the last
one can be sparse/dynamic, since it's the name:value pair that gives it that
characteristic.
- Insertion is simpler for us in some ways than Oracle's nested tables; we're
still inserting "rows" even in the transposed case. Where to put the row key
(and column "path", in the sparse case) is the main question.
- I kind of like the UNQL document-like syntax for updates ({{UPDATE table SET
x.y.z = foo WHERE key = bar}}) but that doesn't preserve the transposition
conceptual integrity.
Still thinking through this.
> CQL support for compound columns
> --------------------------------
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Eric Evans
> Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 1.1
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
