cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12216) TTL Reading And Writing is Asymmetric
Date Wed, 20 Jul 2016 08:42:20 GMT


Sylvain Lebresne commented on CASSANDRA-12216:

bq. Which actually also is incorrect since a negative TTL is not allowed

Right, that's a mistake in the documentation; we internally use <= 0 for no TTL which is
one whomever wrote the doc (possibly me) made the mistake. I'm not sure there is much value
in allowing negative values if we already support 0 and {{null}}, so let's maybe just update
the doc accordingly.

bq. This looks like it should apply to previous versions, going back to 2.1 even.

This is an improvement, as we never pretended supporting {{null}} before. Improvements goes
to trunk, so no.

> TTL Reading And Writing is Asymmetric 
> --------------------------------------
>                 Key: CASSANDRA-12216
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Russell Spitzer
>            Assignee: Russell Spitzer
>            Priority: Minor
>             Fix For: 3.x
>         Attachments: 12216-3.7-2.txt, 12216-3.7.txt
> 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
> I think we should discuss whether `null` should be treated as 0 in TTL for prepared statements.

This message was sent by Atlassian JIRA

View raw message