[jira] [Commented] (CASSANDRA-5674) Inserting Zero Byte values via CQL for types other than Ascii / binary

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-5674:
---------------------------------------------

bq. Which is okay if null implicitly means "delete"

For the sake of being precise, the meaning of null pretty universally mean the absence of a value. Thrift never really allowed this, it was allowing an empty byte array as a valid value for any type. That's different from a null value: for instance, for strings, an empty byte array is the empty string, and no language/database that I know of consider that equivalent to a null string.

That's why using null to represent empty bytes values is not a valid solution in the context CASSANDRA-5648.

Now, imho, supporting empty values for type like int is more of a bug of thrift than a feature. No language supports an empty value (which again, is different from null) for an int so working with such value will just be a pain in practice (and while thrift drivers might have gotten away returning null for such empty values for types that don't really support empty values, CQL3 does support null values (with it's "normal" meaning of the absence of value), so it's not going to fly).

So I think people should avoid empty values for type for which it doesn't really make sense. But for thrift upgrades, the good news is that thrift *can* input such empty values:
{noformat}
INSERT INTO foo(key1, key2, key3,value) VALUES ('test', blobAsTimeuuid(0x), 'test', '');
{noformat}
which has the advantage of making it clear what this is doing. Another solution is to use a prepared statement (where values are inputed as bytes directly so passing an empty byte array for any type will be fine).

I'll note that if you do a {{SELECT}} after the insertion above in cqlsh, it will display null for the key2 value. But that's a bug really and I'll open a ticket to fix.

                
> Inserting Zero Byte values via CQL for types other than Ascii / binary
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-5674
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5674
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Tobias Schlottke
>
> Hi there, 
> we're currently upgrading from thrift to cql and are experiencing another problem with "null" values (similar to #CASSSANDRA-5648).
> I respect the fact that null means delete and that I have to insert a zero byte value but what is the right zero byte value for types other than ascii/blob?
> Usecase:
> {code}
> CREATE TABLE foo (
>   key1 ascii,
>   key2 timeuuid,
>   key3 ascii,
>   value ascii,
>   PRIMARY KEY (key1, key2, key3)
> ) WITH COMPACT STORAGE;
> {code}
> I got a clustering key on three columns and want to insert an "empty" value for the Timeuuid in the middle (key2).
> For data already inserted via thrift I see "null" for all relevant columns already in there, which would be my desired behaviour.
> trying this:
> {code}
> insert into foo(key1,key2,key3) values('test', null, 'test');
> {code}
> returns 
> {code}
> Bad Request: Invalid null value for clustering key part key2
> {code}
> Which is okay if null implicitly means "delete".
> The question is: Am I able to insert a zero byte value for a type like timeuuid that will be compatible with my old dataset where "null" values where possible via thrift?
> Best,
> Tobias

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