[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629002#comment-17629002
]
Andres de la Peña commented on CASSANDRA-17967:
-----------------------------------------------
[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:17967-trunk]
is a draft patch.
#
[Here|https://github.com/adelapena/cassandra/commit/3354f1339fc3f75cdcadd8f654a5ce2ffd441cf4]
it adds a brief reason of AF is pernicious to the documentation of the
{{allow_filtering_enabled}} property in {{cassandra.yaml}}:
{code:java}
# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
# ALLOW FILTERING can potentially visit all the data in the table and have
unpredictable performance.
# allow_filtering_enabled: true{code}
I guess that any user finding the guardrail violation error would land there,
so it seems a good place to document the reason for disabling it. We should
probably add similar reasons for all other guardrails and guardrail-like
properties.
#
[Here|https://github.com/adelapena/cassandra/commit/852afe334318b86483a916c6533c876a486c3045]
it adds a "reason" optional string attribute to every guardrail, so it's
printed right after the guardrail violation error message. For the AF guardrail
the full message is:
{code:java}
> SELECT * FROM k.t WHERE v = 2 ALLOW FILTERING;
Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not
allowed. ALLOW FILTERING can potentially visit all the data in the table and
have unpredictable performance.{code}
Other guardrails don't use this "reason" property, but we should probably start
using them.
#
[Here|https://github.com/adelapena/cassandra/commit/b8ebb7bbfc6f8c9c3247bca70a887f52c64e503f]
it makes the message for missing AF depend on whether the guardrail is enabled
or not. So if a query without AF requires filtering it prints exactly the same
message as before, which is:
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have
unpredictable performance. If you want to execute this query despite the
performance unpredictability, use ALLOW FILTERING{code}
But if the guardrail is disabling AF, the message is
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have
unpredictable performance. Executing this query despite the performance
unpredictability with ALLOW FILTERING has been disabled by the
allow_filtering_enabled property in cassandra.yaml{code}
The commit is a bit noisy due to the need to make the {{ClientState}} available
to {{{}StatementRestrictions{}}}.
> Guardrail: allow_filtering_custom_error_message
> -----------------------------------------------
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Sarma Pydipally
> Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> <stdin>:1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
