Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 10 Aug 2016 20:02:22 +0000 (UTC)
From: "Benjamin Lerer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12989929.1468613807000.275864.1470859342335@Atlassian.JIRA>
In-Reply-To: <JIRA.12989929.1468613807000@Atlassian.JIRA>
References: <JIRA.12989929.1468613807000@Atlassian.JIRA> <JIRA.12989929.1468613807361@arcas>
Subject: [jira] [Commented] (CASSANDRA-12216) TTL Reading And Writing is
 Asymmetric
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 10 Aug 2016 20:02:26 -0000


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

Benjamin Lerer commented on CASSANDRA-12216:
--------------------------------------------

I did not have time to review the patch yet. I try to do it before the end of the week. Sorry, for the delay. 

> TTL Reading And Writing is Asymmetric 
> --------------------------------------
>
>                 Key: CASSANDRA-12216
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12216
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Russell Spitzer
>            Assignee: Russell Spitzer
>            Priority: Minor
>             Fix For: 3.x
>
>         Attachments: 12216-3.7-2.txt, 12216-3.7.txt, 12216-trunk.patch
>
>
> There is an inherent asymmetry in the way TTL's are read and Written. 
> An `TTL` of 0 when written becomes a `null` in C*
> When read, this `TTL` becomes a `null` 
> The `null` cannot be written back to C* as `TTL`
> This means that end users attempting to copy tables with TTL have to do manual mapping of the null TTL values to 0 to avoid NPE. This is a bit onerous when C* seems to have an internal logic that 0 == NULL. I don't think C* should return values which are not directly insertable back to C*. 
> Even with the advent CASSANDRA-7304 this still remains a problem that the User needs to be aware of and take care of.
> The following prepared statement
> {code}
> INSERT INTO test.table2 (k,v) (?,?) USING TTL: ? 
> {code}
> Will throw NPEs unless we specifically check that the value to be bound to TTL is not null.
> I think we should discuss whether `null` should be treated as 0 in TTL for prepared statements. 


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