Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 20 Dec 2011 15:27:31 +0000 (UTC)
From: "Jonathan Ellis (Updated) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <170117335.31084.1324394851296.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1760266686.58147.1302800105858.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis updated CASSANDRA-2474:
--------------------------------------

    Attachment: 2474-transposed-select-no-sparse.PNG

bq. I would say that 'sucking much less' doesn't necessarily make it 'the right solution'.

This is more than sucking less. This is adapting exactly to the relational philosophy that SQL is about sets of records and predicates that deal with them, and how things are stored is an implementation detail.  I don't see how we can do better than this or something like it.

bq. Typically, you can do {{UPDATE test1 SET prop2 = 42 WHERE key = 'someKey'}} but you cannot do the same [statement] on test2. 

That's a good point, although I think the limitations are fairly easy to explain, along with the effect on ordering.

bq. The SPARSE don't add any new possibility, it just adds a presumably better syntax for a specific case. 

Technically that is true, but that is akin to arguing that because PHP is Turing complete it's as good as Java to write databases in. :)

Consider my timeline example.  If we defined the table without SPARSE, as
{noformat}
CREATE TABLE timeline (
    userid int primary key,
    posted_at uuid,
    column string,
    value blob
) TRANSPOSED
{noformat}

The query {{SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_at > 1770}} would give us 

!2474-transposed-select-no-sparse.PNG!

I don't see how this is usable in any reasonable sense of the word.  Am I missing something?

(And no, "just model it with dense composites" is not an option for the mview use case, where adding new columns requires rebuilding the entire CF.  That's a big win for us, and I'm not willing to give it up.)

bq. I would actually be in favor of having the first step on this being the addition of a very simple 'raw' notation to access composites.

I'm strongly against this or any "row slicing" notation, it's a terrible fit for anything that wants to deal with resultsets of rows sharing a common set of columns (i.e., CQL and its drivers). Unless this actually returns rows instead of columns which is not at all implied by the syntax. Strongly against that too. :)
                
> 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