[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS

["Stefan Miklosovic (Jira)" <ji...@apache.org>]

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

Stefan Miklosovic commented on CASSANDRA-18042:
-----------------------------------------------

{code}
sai_indexes_take_snapshots_warned: true
sai_indexes_take_snapshots: false
sai_indexes_warned: true
sai_indexes_enabled: false
{code}

_In the above example, would we allow sai indexes and warn when used? Would we disallow them and not warn?_

We would disallow sai indexes and emit a failure so we would not warn. So the second option of yours.

For better clarity, I would order the properties in yaml differently:

{code}
# enables taking snapshots on sai indexes, if false, warn flag is irrelevant
sai_indexes_take_snapshots: false
sai_indexes_take_snapshots_warned: true
# enables sai indexes, if false, warn flag is irrelevant
sai_indexes_enabled: false
sai_indexes_warned: true
{code}

The motivation behind that is that the documentation / yaml is read from the top to the bottom, not vice versa. If there was "warn" first a reader understands it "ok we are going to warn here" just to be informed on the next line that she is actually not going to be warned because it is not enabled. With this new way of ordering, she can comfortably just skip everything else after that.

To wrap it up, yes, this is new way of doing things, dependent properties. If you do not want to do that, I am not sure how to achieve that, maybe having a guardrail which would accept more values? Like this:

{code}
sai_indexes: {enabled, warned, disabled}
{code}

You know what I mean ... This leads to "custom guardrails" which could deal with this kind of stuff. Custom guardrails are part of my Password Generation and Validation CEP proposal. If me managed to implement that CEP, this behaviour would be available virtually for free.



> 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
>
>          Time Spent: 3h
>  Remaining Estimate: 0h
>
> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org