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, 19 Jun 2014 09:42:24 GMT

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

Sylvain Lebresne commented on CASSANDRA-7304:
---------------------------------------------

How does having the option at the protocol level change this in any way? You're just hiding
things a bit more making it easier for people to don't understand what's going on, but you'll
still have statements with 'ignore null' set but who don't set any value to null. Besides,
there's many way to have 2 different statements doing the same thing so it's not like we'd
create some kind of horrible inconsistency. Take:
{noformat}
UPDATE table SET s = s + { 3 }, s = s + { 4 } WHERE k = 2;
UPDATE table SET s = s + { 3, 4 } WHERE k = 2;
UPDATE table SET s = s + { 3, 4 } WHERE k = blobAsInt(intAsBlob(2));
{noformat}
Besides, people are not stupid. No-one will get completely confused that IGNORE_NULLS is a
no-op if there is no null in the query.

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

Mime
View raw message