cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3783) Add 'null' support to CQL 3.0
Date Mon, 11 Feb 2013 12:23:14 GMT

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

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

As far as the parser go this is fine (except that since null is a keyword, I'd rather call
the token K_NULL for consistency sake).

But otherwise I don't think treating null as the empty string is a good idea.  As you say
it doesn't work for strings, but even for other types, inserting an empty byte buffer is not
the intent (and in fact this would probably break some type of querying since the empty byte
buffer is kind of reserved and special cased in query slices). The intent, as far as inserts/updates
are concerned is that setting the column to null is equivalent to not setting it at all, it's
just a convenience. Which means that we probably need special handling in the Operation classes
(we'll need that special treatment for handling null in prepared statement anyway (CASSANDRA-5081,
which is probably the most useful part of supporting nulls)).

For selects however, null is actually a constraint on the query. For that, we may want/need
to update the 2ndary index code to handle that. But maybe that part could be done separatly
in fact.

I do want to note that the example in the description of this ticket is kind of bad. In theory,
a PRIMARY KEY cannot contain a null value by definition and currently we don't allow them
in general. The example in the description is one exception (compact + composite) where we
could indeed allow some nulls in the PK, but since it is a special case, maybe we can leave
that to a follow up ticket.

                
> 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
>            Priority: Minor
>              Labels: cql3
>             Fix For: 1.2.2
>
>         Attachments: 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

Mime
View raw message