[
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
