[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156282#comment-14156282
]
Sylvain Lebresne commented on CASSANDRA-7304:
---------------------------------------------
The general principle of using -1 for 'nulls' and -2 for 'unset' in the
protocol is fine but:
* We need to document the changes. I've pushed a v4 spec doc on trunk which
should be modified to document those change (and list them in the changelog at
the end of the document).
* We should take the protocol version into account. Pre-v4 protocol assume that
if the size of a value is < 0, it represents null and we need to preserve that
(one could hope that divers always use -1 for null in practice, but that wasn't
specified that way so...). Which will probably mean pushing the protocol
version to {{CBUtil.readValue}}.
* Once we have unset values in the protocol, {{Constants.Setter}} is far from
being the only place were we could get them. In pretty much every place where
we do a {{bind()}} (or {{bindAndGet()}}) we need to be warry of
{{UNSET_BYTE_BUFFER}} (even if it's just to reject it as a non-sensical value).
* It's a nit, but for the v4 protocol, instead of saying "-2 is unset and any
other negative value is null", I'd just say "-1 is null, -2 is unset and any
other negative value is invalid".
* Not convinced of the {{CQLTester}} modification. Instead of modifying
{{CQLTester}}, I'd just use plain old {{execute}} but pass
{{CBUtil.UNSET_BYTE_BUFFER}} in the concrete tests. We should also extend tests
to cover unset for collections, UDT, counter updates, etc... (which as said
above are not handled properly by the current patch).
> 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
> Labels: cql, protocolv4
> Fix For: 3.0
>
> Attachments: 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)
