You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Tyler Hobbs (JIRA)" <ji...@apache.org> on 2014/08/19 20:33:18 UTC

[jira] [Created] (CASSANDRA-7792) Fix cqlsh null handling in COPY FROM

Tyler Hobbs created CASSANDRA-7792:
--------------------------------------

             Summary: Fix cqlsh null handling in COPY FROM
                 Key: CASSANDRA-7792
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7792
             Project: Cassandra
          Issue Type: Bug
          Components: Tools
            Reporter: Tyler Hobbs
            Assignee: Tyler Hobbs
            Priority: Minor
             Fix For: 2.1.0


In {{create_insert_statement()}}, we have the following logic:

{noformat}
if value != nullval:
    if cqltype in ('ascii', 'text', 'timestamp', 'inet'):
        rowmap[name] = protect_value(value)
    else:
        rowmap[name] = value
elif name in clustering_key_columns and not type.empty_binary_ok:
    rowmap[name] = 'blobAs%s(0x)' % cqltype.title()
else:
    rowmap[name] = 'null'
{noformat}

The first problem is that we're inserting empty binaries when the type should _not_ have empty binaries.

However, it could also be considered incorrect that we insert empty binaries for clustering columns when we have something that matches the "null value".  This is to avoid inserting nulls for clustering columns.  Of course, users may actually want to insert empty strings for columns, but I think that if they want that behavior, changing the null value is the correct way to do that.

I propose changing the "elif" statement to something like:

{noformat}
elif name in primary_key_columns:
    raise Exception("Nulls are not allowed in primary key columns")    
{noformat}

I set the fix version for this to 2.1.0.  If we're not comfortable making this entire change in 2.1.0, we should at least remove the "not" in the elif and make the other changes for 2.1.1



--
This message was sent by Atlassian JIRA
(v6.2#6252)