[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173487#comment-13173487
 ] 

Jonathan Ellis commented on CASSANDRA-2474:
-------------------------------------------

bq. you simply can't represent slices of wide, composite rows sanely that way 
without something like transposition to expose the structure "hidden" 
underneath.

Put another way: we've always said the "right" way to model is to have one 
"atom" of data per CF -- that is, data that is queried together should go in 
the same CF.  But, we haven't enforced this in the API.  From my perspective, 
that's a bug, not a feature.  If we *do* have a single type of data (or type of 
record) per CF, then we can make relational-style resultsets out of it; the 
only question is, how do we expose that in the query language.  And the 
conclusion I'm coming to is that we shouldn't have to change the language; 
CQL-modeled-on-SQL is already good at describing sets of a given type of data.  
So the right thing to do is to provide hints in the DDL that tell Cassandra how 
to represent it at definition time, rather than at query time.

"Document" data doesn't change this, it's just an expansion of what we consider 
a "record" or "atom".  Should we be able to have wide rows of documents?  Yes.  
(E.g., by having a column type "json.")  But I don't think we need to boil that 
ocean here.

TLDR: I am totally fine with having some constructs technically representable 
using composite columns, that we don't actually allow building from the API.  
Total schema-freedom is not a design goal.
                
> 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: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 
> 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, 
> raw_composite.txt, 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

        

Reply via email to