cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Spitzer (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12216) TTL Reading And Writing is Asymmetric
Date Tue, 19 Jul 2016 17:30:20 GMT


Russell Spitzer commented on CASSANDRA-12216:

Currently the latest version states
TTL: allows to specify an optional Time To Live (in seconds) for the inserted values. If set,
the inserted values are automatically removed from the database after the specified time.
Note that the TTL concerns the inserted values, not the column themselves. This means that
any subsequent update of the column will also reset the TTL (to whatever TTL is specified
in that update). By default, values never expire. A TTL of 0 or a negative one is equivalent
to no TTL.

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

  if (ttl < 0)
            throw new InvalidRequestException("A TTL must be greater or equal to 0, but was
" + ttl);

> 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
>         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