[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887860#comment-16887860
]
Laxmikant Upadhyay edited comment on CASSANDRA-14227 at 7/23/19 5:23 AM:
-------------------------------------------------------------------------
Resuming the {{localDeletionTime}} value as discussed here after an update
operation 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 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 we TTL value is no more 20 years
(630720000).
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}
was (Author: laxmikant99):
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: [email protected]
For additional commands, e-mail: [email protected]
