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

Drew Kutcharian commented on CASSANDRA-7304:
--------------------------------------------

I agree with [~slebresne] here. Having it on the query is much clearer and 
easier to read. Also, I don't see a problem with having multiple statements 
that do the same thing, since:

bq. UPDATE table SET column = 3 WHERE key = 2;
This means use the default behavior

bq. UPDATE table USING IGNORE_NULLS true SET column = 3 WHERE key = 2;
This explicitly sets USING IGNORE_NULLS to true.

bq. UPDATE table USING IGNORE_NULLS false SET column = 3 WHERE key = 2;
This explicitly sets USING IGNORE_NULLS to false. Say if the default ever 
changes and you just don't want to be at the mercy of the "default".

So I wouldn't say these 3 statements have the same meaning.

> Ability to distinguish between NULL and UNSET values in Prepared Statements
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7304
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Drew Kutcharian
>
> Currently Cassandra inserts tombstones when a value of a column is bound to 
> NULL in a prepared statement. At higher insert rates managing all these 
> tombstones becomes an unnecessary overhead. This limits the usefulness of the 
> prepared statements since developers have to either create multiple prepared 
> statements (each with a different combination of column names, which at times 
> is just unfeasible because of the sheer number of possible combinations) or 
> fall back to using regular (non-prepared) statements.
> This JIRA is here to explore the possibility of either:
> A. Have a flag on prepared statements that once set, tells Cassandra to 
> ignore null columns
> or
> B. Have an "UNSET" value which makes Cassandra skip the null columns and not 
> tombstone them
> Basically, in the context of a prepared statement, a null value means delete, 
> but we don’t have anything that means "ignore" (besides creating a new 
> prepared statement without the ignored column).
> Please refer to the original conversation on DataStax Java Driver mailing 
> list for more background:
> https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion



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

Reply via email to