[ 
https://issues.apache.org/jira/browse/CASSANDRA-17372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490529#comment-17490529
 ] 

Paulo Motta commented on CASSANDRA-17372:
-----------------------------------------

Thanks all for the support and initial feedback.

bq. If we did this purely based on insert timestamp and repair status this 
would be very easy

can you elaborate on why repair state is relevant here?

bq. I think it is fine to simply document that TTL-expiry is non-deterministic, 
and that without a major compaction you can expect data resurrection if you set 
the TTL up again later.

I think we can make this a little safer by exposing some cluster-level metadata 
about the state of TTL change and prevent a new TTL change if there is still 
data not honoring the current TTL.

> Dynamic Table TTL
> -----------------
>
>                 Key: CASSANDRA-17372
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17372
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Semantics
>            Reporter: Paulo Motta
>            Priority: Normal
>
> One limitation of the {{default_time_to_live}} option is that it only applies 
> to newly inserted data so an expensive migration is required when altering 
> the table-level TTL, which is not an uncommon request due to changes in 
> retention policies.
> This seems to have been a deliberate design decision when adding the Table 
> TTL feature on CASSANDRA-3974, due to the reasons stated [on this 
> comment|https://issues.apache.org/jira/browse/CASSANDRA-3974?focusedCommentId=13427314&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13427314]
>  so we should revisit and potentially address these concerns.
> I would like to explore supporting dynamic TTL, which would reflect any 
> updates to the table-level {{default_time_to_live}} immediately to all table 
> data.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to