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

["Ben Hood (JIRA)" <ji...@apache.org>]

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

Ben Hood commented on CASSANDRA-7304:
-------------------------------------

We've had [an issue raised with us at gocql|https://github.com/gocql/gocql/issues/296] that would like to take advantage of these changes, but I'm not 100% what the final scope of this patch will be. One first glance it looked like these were just driver side changes, and hence we were considering to what extent we could replicate this in our driver. There was mention that the wire protocol would be clarified to include the UNSET (-2) flag. But reading the latest patch, it looks like there might be some server side changes as well.

To be fair, it looks like the understanding of what needs to happen has evolved since the issue was first raised. So I was wondering whether the intention of this can get restated of the benefit of external readers.

Would it be possible to update the original summary to reflect the current motivation and scope of the change?

> 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: Sub-task
>            Reporter: Drew Kutcharian
>            Assignee: Oded Peer
>              Labels: cql, protocolv4
>             Fix For: 3.0
>
>         Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
>
>
> 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.3.4#6332)