[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634008#comment-17634008
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/14/22 7:15 PM:
-------------------------------------------------------------------------
I do not mind to have it like Josh says. What is more probable?
a) that people will use TWCS and they forget to set default_time_to_live to
something else from 0 and
OR
b) we leave it as it is and the operators will go over all guardrails on a
rainy Sunday and say "ah this one is nice, maybe we should use it just to be
sure".
I would say that a) is more probable. People solve problems most often
re-actively. It is better if there is a safety net and they do not even notice.
If users want to have it with 0, they would need to turn this off explicitly
and that is I guess a minority.
Does this relates to what you see in the field?
was (Author: smiklosovic):
I do not mind to have it like Josh says. What is more probable?
a) that people will use TWCS and they forget to set default_time_to_live to
something else from 0 and
OR
b) we leave it as it is and the operators will go over all guardrails on a
rainy Sunday and say "ah this one is nice, maybe we should use it just to be
sure".
I would say that a) is more probable. People solve problems most often
re-actively. It is better if there is a safety net and they do not even notice.
If power users want to have it with 0, they would need to turn this off
explicitly and that is I guess is minority.
Does this relates to what you see in the field?
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.x
>
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
