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

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

bq. In the non-sparse case you always would always ignore the column value?

No, it would be associated with the last column definition.

bq. for users who are coming from thrift they will be asking "how do i access 
data from my current data model?"

bq. Requiring a ALTER when you may not know what columns you have is too 
restrictive. Example, a ETL from a 3rd party manufacturer that provides a 
custom set of attributes per product: some standard (Unit Price, Model, Color, 
etc) some specific (DPI, Shipping Size, Contrast Ratio). 

But that's exactly when you *do* know what columns you have.  (We're totally 
fine with having most sparse columns be null.)  What we can't do is query 
"undefined" columns.  *This is inherent to any transposition approach*, even 
the earlier ones above.  The only way we can support that is by destructuring 
each column into a resultset of (key, columnname, columnvalue).

I can't think of a single example where wide rows with actual different 
structure (as opposed to just sparse columns as in your example here) is the 
Right Way to do things.  If this is actually necessary though then I think we 
should add separate syntax for the destructuring approach.

bq. what if a user wants to access data in composite form and "raw" 
[non-transposed] mode, should we support multiple "views" on the CF

No.  Nested-but-not-transposed data aka "documents" is another separate case.
                
> 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

        

Reply via email to