You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Laxmikant Upadhyay (JIRA)" <ji...@apache.org> on 2019/07/18 10:34:00 UTC
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[ https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887860#comment-16887860 ]
Laxmikant Upadhyay commented on CASSANDRA-14227:
------------------------------------------------
Resuming the {{localDeletionTime}} value after update on a row with TTL does not look feasible. Please see the below test case:
*Step 1:*
insert into tab3(id,key,value) VALUES('id2', 'key1', 2) USING TTL 630720000; (20 years).
{code:java}
sstabletojson:
{
"partition" : {
"key" : [ "id2" ],
"position" : 33
},
"rows" : [
{
"type" : "row",
"position" : 75,
"clustering" : [ "key1" ],
"liveness_info" : { "tstamp" : "2019-07-18T07:03:22.198Z", "ttl" : 630720000, "expires_at" : "2038-01-19T03:14:06Z", "expired" : false },
"cells" : [
{ "name" : "value", "value" : 2 }
]
}
]
}{code}
*Step 2:*
1. select ttl(value) from tab3 where id='id2';
This results 584043668 ! 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.
2. insert into tab3(id,key,value) VALUES('id2', 'key1', 3) USING TTL 584043668;
{code:java}
sstabletojson:
{
"partition" : {
"key" : [ "id2" ],
"position" : 33
},
"rows" : [
{
"type" : "row",
"position" : 75,
"clustering" : [ "key1" ],
"liveness_info" : { "tstamp" : "2019-07-18T08:54:27.921Z", "ttl" : 584043668, "expires_at" : "2038-01-19T03:14:06Z", "expired" : false },
"cells" : [
{ "name" : "value", "value" : 3 }
]
}
]
}{code}
> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org