[ https://issues.apache.org/jira/browse/CASSANDRA-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394505#comment-15394505 ]
Russell Spitzer commented on CASSANDRA-12216: --------------------------------------------- New patch attached vs Trunk, contains doc changes as well > 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)