[
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
