cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Michalski (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-3783) Add 'null' support to CQL 3.0
Date Wed, 20 Feb 2013 09:09:14 GMT

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

Michał Michalski edited comment on CASSANDRA-3783 at 2/20/13 9:09 AM:
----------------------------------------------------------------------

OK, here's the patch. In general I've added possibility to check TYPE of classes implementing
Term.Raw (more precise: checking if they're NULLs) and use it in Operations classes implementing
RawUpdate (in one of these classes, actually). If Term Type is NULL, return Constants.Deleter
Operation when preparing operation.

Quick explaination:

Why, among all the classes containing nested Literal classes implementing Term.Raw, only one
checks for Term Type and rest of them return false by default?
* Constants: it checks the Type because, obviously, this is the main null-value use case
* Sets, Lists, Maps: If one of them is set to null it's matched (by parser) as a null-based
Constant (which seems to be fine from my point of view, doesn't it?), so none of them can
be of type null itself
* TypeCast, FunctionCall, AbstractMarker: it just doesn't make sense for them to be null

Why only SetValue (among other RawUpdate interfaces) checks if Term is NULL and returns Deleter
if yes:
* RawUpdate:
    SetValue: obviously, this was the main use case here
    SetElement: setting collections' values to null might make sense, but do we want it?
    Addition, Substraction, Prepend: adding null to existing column's contents etc. doesn't
make sense for me
* RawDeletion: If we do not support nulls in SELECTs because of the indexing reasons, I guess
it can't be done in DELETEs too

Additionally I renamed NULL to K_NULL, as suggested.
                
      was (Author: michalm):
    OK, here's the patch. In general I've added possibility to check TYPE of classes implementing
Term.Raw (more precise: checking if they're NULLs) and use it in Operations classes implementing
RawUpdate (in one of these classes, actually). If Term Type is NULL, return Constants.Deleter
Operation when preparing operation.

Quick explaination:

Why, among all the classes containing nested Literal classes implementing Term.Raw, only one
checks for Term Type and rest of them return false by default?
* Constants: it checks the Type because, obviously, this is the main null-value use case
* Sets, Lists, Maps: If one of them is set to null it's matched (by parser) as a null-based
Constant (which seems to be fine from my point of view, doesn't it?), so none of them can
be of type null itself
* TypeCast, FunctionCall, AbstractMarker: it just doesn't make sense for them to be null

Why only SetValue (among other RawUpdate interfaces) checks if Term is NULL and returns Deleter
if yes:
* RawUpdate:
    SetValue: obviously, this was the main use case here
    SetElement: setting collections' values to null might make sense, but do we want it?
    Addition, Substraction, Prepend: adding null to existing column's contents etc. doesn't
make sense for me
* RawDeletion: If we do not support nulls in SELECTs because of the indexing reasons, I guess
it can't be done in DELETEs too

                  
> 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-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

Mime
View raw message