[ https://issues.apache.org/jira/browse/CASSANDRA-17372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490512#comment-17490512 ]
Jeremiah Jordan commented on CASSANDRA-17372: --------------------------------------------- I think we should indeed do this, but we should use "expiration time" or some other phrase to talk about this new thing. This would be something completely separate from the per cell TTL we currently have, which is what CQL and current table level TTL are setting. Then we just document that for a table with an expiration time set the data timestamp must be in the same format. > 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