cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
Date Thu, 02 Oct 2014 09:55:34 GMT

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

Mime
View raw message