cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns
Date Tue, 20 Dec 2011 15:29:32 GMT

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

Jonathan Ellis edited comment on CASSANDRA-2474 at 12/20/11 3:29 PM:
---------------------------------------------------------------------

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?

(Edit: it's actually worse than that, since you can't even use 'posted_at' in the query. 
I've actually written SQL with "dynamic columns" like this and I cannot overemphasize how
badly it sucks.)

(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. :)
                
      was (Author: jbellis):
    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

        

Mime
View raw message