[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622147#comment-17622147
]
Benjamin Lerer edited comment on CASSANDRA-17967 at 10/21/22 9:13 AM:
----------------------------------------------------------------------
[~brandon.williams] proposal make sense to me.
{quote}Pretty sure [~blerer] spent some cycles on working on mapping error
codes at some point; there's so much in the system at this point that trying to
"boil the ocean" on the topic isn't viable.\{quote}
I effectively spent a couple of months trying to come up with a solution for
error codes and error messages. At this stage it is really a hard problem to
solve.
Regarding custom messages, we can allow additional information to be passed to
message but not more in my opinion. I have seen too many bugs where the only
information provided was a simple error message. If the error messages start to
be custom ones it will become impossible for us to track down where the error
is coming from.
was (Author: blerer):
[~brandon.williams] proposal make sense to me.
{quote}Pretty sure [~blerer] spent some cycles on working on mapping error
codes at some point; there's so much in the system at this point that trying to
"boil the ocean" on the topic isn't viable.\{quote}
I effectively spent a couple of months trying to come up with a solution for
error codes and error messages. At this stage it is really a hard problem to
solve.
Regarding custom messages, we can allow additional information to be passed to
message but not more in my opinion. I have seen too many bugs where the only
information provided was a simple error message. If the error messages start to
be custom ones it will become impossible for us to track down where the error
is coming from.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
