[ https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890992#comment-16890992 ]
Paulo Motta commented on CASSANDRA-14227: ----------------------------------------- {quote}This results 584043668 and not 630720000 ! and then updating the row with fetched ttl loses the original ttl value (20 years) so resuming localDeletionTime based on ttl the value will not be feasible if someone chooses CAP or CAP_NOWARN option as in sstable, TTL value is no more 20 years (630720000). {quote} The fact that {{SELECT TTL(*)}} does not return the original TTL does not mean we cannot resume the original TTL once this is fixed. Data will need to be rewritten via "upgradesstables" to restore the original TTL once this limitation is fixed. If you are updating the row with fetched TTL you are overwriting the original value, so it's expected behavior that you lose the original TTL. If you are willing to take a stab at fixing this, I think the simplest approach is to change the {{localDeletionTime}} field from integer to long. > Extend maximum expiration date > ------------------------------ > > Key: CASSANDRA-14227 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14227 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths > Reporter: Paulo Motta > Priority: Normal > > The maximum expiration timestamp that can be represented by the storage > engine is > 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as > an int32. > On CASSANDRA-14092 we added an overflow policy which rejects requests with > expiration above the maximum date as a temporary measure, but we should > remove this limitation by updating the storage engine to support at least the > maximum allowed TTL of 20 years. -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org