[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047322#comment-13047322
]
T Jake Luciani commented on CASSANDRA-2474:
-------------------------------------------
bq. No, that really doesn't give me details at all. All that tells me is that I
can use magic, hard-coded column names to support wide rows with no subcolumns.
(I assume subcolumns are supported too but this does not tell me now.)
You didn't read it all then :) you can specify the following column mappings in
cassandra.columns.mapping:
:key = row key
:column = column/supercolumn name
:subcolumn = subcolumn
:value = value
bq. (This is the same reason people always regret saying "I know, I'll bypass
the problems of having to do ALTER TABLE in mysql by creating a table that has
two columns, key and value.")
I agree but this is why subselects work in the case of hive.
bq. Which comes back to my original argument that this is the right level of
granularity for the API to encourage, or you've screwed up your data model.
This is why I said it's hard todo in the case of Hive since you are going to be
doing a map reduce on most/all the data anyway. Or are you arguing that we
shouldn't allow access to all rows in hive?
> 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
> Labels: cql
> Fix For: 1.0
>
>
> 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
