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

Sylvain Lebresne commented on CASSANDRA-3783:
---------------------------------------------

bq. It would also be convenient if CQL3 supported null values for collections.

I'm afraid this is not so simple I'm afraid. Doing that would basically require 
having an internal representation of null for every type (because in that case, 
we would be talking of actually storing a null value, not just deleting a 
column). And we don't have an easy candidate for that internal representation 
currently. Meaning we would have to change a bit the internal representation of 
collection columns (say, add some flags somewhere in the column name that say 
"this is a null element"). But I'm not convinced we can do that without 
breaking backward compatibility really. In any case, this is a very special 
case so we should handle that in a followup ticket if we do handle. But again, 
not sure how doable that is in practice.

{quote}
Say I have 
ALTER TABLE metrics ADD valueBySecond list<double>;
{quote}
Just for the record, this sound like a bad use of a list. Because valueBySecond 
sound like something that by design will grow fairly big. Remember that 
currently you cannot fetch parts of a collection. And even when we allow 
fetching part of a collection, we'll only be able to do it for maps and sets, 
not for lists. This is typically a case where you'd rather want to have a 
composite PK.
                
> Add 'null' support to CQL 3.0
> -----------------------------
>
>                 Key: CASSANDRA-3783
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>            Reporter: Sylvain Lebresne
>            Assignee: MichaƂ Michalski
>            Priority: Minor
>              Labels: cql3
>             Fix For: 1.2.3
>
>         Attachments: 3783-v2.patch, 3783-wip-v1.patch
>
>
> Dense composite supports adding records where only a prefix of all the 
> component specifying the key is defined. In other words, with:
> {noformat}
> CREATE TABLE connections (
>    userid int,
>    ip text,
>    port int,
>    protocol text,
>    time timestamp,
>    PRIMARY KEY (userid, ip, port, protocol)
> ) WITH COMPACT STORAGE
> {noformat}
> you can insert
> {noformat}
> INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1', 
> 80, 123456789);
> {noformat}
> You cannot however select that column specifically (i.e, without selecting 
> column (2, '192.168.0.1', 80, 'http') for instance).
> This ticket proposes to allow that though 'null', i.e. to allow
> {noformat}
> SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port = 
> 80 AND protocol = null;
> {noformat}
> It would then also make sense to support:
> {noformat}
> INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2, 
> '192.168.0.1', 80, null, 123456789);
> {noformat}
> as an equivalent to the insert query above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to