Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 18 Dec 2014 12:50:14 +0000 (UTC)
From: "Oded Peer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12716684.1401134419000.56931.1418907014557@Atlassian.JIRA>
In-Reply-To: <JIRA.12716684.1401134419000@Atlassian.JIRA>
References: <JIRA.12716684.1401134419000@Atlassian.JIRA>
 <JIRA.12716684.1401134419491@arcas>
Subject: [jira] [Commented] (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.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14251604#comment-14251604 ]=20

Oded Peer commented on CASSANDRA-7304:
--------------------------------------

[~0x6e6562] I updated the original summary.

> 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: 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.pat=
ch
>
>
> 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
> *EDIT 18/12/14 - [~odpeer] Implementation Notes:*
> The motivation hasn't changed.
> Protocol version 4 specifies that bind variables do not require having a =
value when executing a statement. Bind variables without a value are called=
 'unset'. The 'unset' bind variable is serialized as the int value '-2' wit=
hout following bytes.
> \\
> \\
> * An unset bind variable in an EXECUTE or BATCH request
> ** On a {{value}} does not modify the value and does not create a tombsto=
ne
> ** On the {{ttl}} clause is treated as 'unlimited'
> ** On the {{timestamp}} clause is treated as 'now'
> ** On a map key or a list index throws {{InvalidRequestException}}
> ** On a {{counter}} increment or decrement operation does not change the =
counter value, e.g. {{UPDATE my_tab SET c =3D c - ? WHERE k =3D 1}} does ch=
ange the value of counter {{c}}
> ** On a tuple field or UDT field throws {{InvalidRequestException}}
> * An unset bind variable in a QUERY request
> ** On a partition column, clustering column or index column in the {{WHER=
E}} clause throws {{InvalidRequestException}}
> ** On the {{limit}} clause is treated as 'unlimited'


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)