[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements

["Oded Peer (JIRA)" <ji...@apache.org>]

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

Oded Peer commented on CASSANDRA-7304:
--------------------------------------

Since values are byte arrays I don't think it's possible to add special values like unset".
I am thinking of two ways to solve this:

1. Add a new flag to the QueryOptions, instructing Cassandra to ignore null values in prepared statements. The default being to create tombstones for backward compatibility.
The advantage of this approach is that it can defined by Cassandra and by the driver to be applied only to prepared statements.
The disadvantage I see in this is that since flags is a represented in a byte this will take up the last Flag slot and make a total of 8 flags.

2. Add a new boolean option to the INSERT and UPDATE commands named IGNORE_NULLS which instructs Cassandra to ignore null values instead of marking them as tombstones.
The advantage of this is that it is explicit and more natural as part of the language syntax.
The disadvantage is that it is not limited to prepared statements and will be confusing.

I prefer the first option.

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