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

Andres de la Peña commented on CASSANDRA-17186:
-----------------------------------------------

[~tejavadali] thanks for the patch. Unfortunately CASSANDRA-17353 has changed 
the format of the configuration for guardrails, so we would need to rebase the 
patch and adapt it to the changes. Sorry for the inconvenience. The updated 
configuration would look like:
{code:java}
# Guardrail to warn or fail when querying with an IN restriction selecting
# more partition keys than threshold.
# The two thresholds default to -1 to disable. 
partition_keys_in_select_warn_threshold: -1
partition_keys_in_select_fail_threshold: -1
{code}
Other than that, the approach overall looks good to me, I have left a few 
comments on the PR. The main point is that we need to pass the {{ClientState}} 
of the query to the guardrail, so it's not applied to super user and internal 
queries.
 

> Guardrail for number of partition keys on IN queries
> ----------------------------------------------------
>
>                 Key: CASSANDRA-17186
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Feature/Guardrails
>            Reporter: Andres de la Peña
>            Assignee: Krishna Vadali
>            Priority: Normal
>              Labels: AdventCalendar2021, lhf
>             Fix For: 4.x
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an 
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable. 
> partition_keys_in_select:
>     warn_threshold: -1
>     abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> *  Add the configuration for the new guardrail on the number of partitions on 
> IN queries in the guardrails section of cassandra.yaml.
> *  Add a getPartitionKeysInSelect method in GuardrailsConfig returning a 
> Threshold.Config object
> *  Implement that method in GuardrailsOptions, which is the default 
> yaml-based implementation of GuardrailsConfig
> *  Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using 
> the previously created config
> *  Define JMX-friendly getters and setters for the previously created config 
> in GuardrailsMBean
> *  Implement the JMX-friendly getters and setters in Guardrails
> *  Now that we have the guardrail ready, it’s time to use it. We should 
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard 
> method with the number of keys specified in select query. The 
> SelectStatement#getSliceCommands methods look like good candidates for this.
> *  Finally, add some tests for the new guardrail. Given that the new 
> guardrail is a Threshold, our new test should probably extend ThresholdTester.



--
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