Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 19 Aug 2014 13:49:18 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12716684.1401134419491.32333.1408456158880@arcas>
In-Reply-To: <JIRA.12716684.1401134419491@arcas>
References: <JIRA.12716684.1401134419491@arcas>
Subject: [jira] [Updated] (CASSANDRA-7304) Ability to distinguish between
 NULL and UNSET values in Prepared Statements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne updated CASSANDRA-7304:
----------------------------------------

    Reviewer: Sylvain Lebresne

> Ability to distinguish between NULL and UNSET values in Prepared Statemen=
ts
> -------------------------------------------------------------------------=
--
>
>                 Key: CASSANDRA-7304
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
>             Project: Cassandra
>          Issue Type: Improvement
>            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 t=
he prepared statements since developers have to either create multiple prep=
ared statements (each with a different combination of column names, which a=
t times is just unfeasible because of the sheer number of possible combinat=
ions) 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 i=
gnore 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 del=
ete, but we don=E2=80=99t have anything that means "ignore" (besides creati=
ng 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/c=
HE3OOSIXBU/discussion


--
This message was sent by Atlassian JIRA
(v6.2#6252)