[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892420#comment-16892420
]
Laxmikant Upadhyay commented on CASSANDRA-14227:
------------------------------------------------
[~pauloricardomg] I believe there are many use-cases where users maintain the
TTL of a row while updating it. Hence in all such cases original TTL will be
lost. So, is it worth giving TTL recalculation feature in upgradesstable which
won't be applicable to all users ?
I agree that a permanent fix, changing {{localDeletionTime}} field from integer
to long is simplest way to go but this change will be big in terms changes in
number of classes and we need to carefully analyse the impact as well.
> 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: [email protected]
For additional commands, e-mail: [email protected]
