[
https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273580#comment-14273580
]
Sylvain Lebresne commented on CASSANDRA-8303:
---------------------------------------------
bq. it doesn't fit anywhere in the hierarchy
Which hierarchy are we talking about? At the very list in Sam's proposal of
syntax, I don't see what would be the problem of having such restrictions. If
this doesn't fit the hierachy of restrictions-as-permissions, then as said
above I think this might point to the lack of flexibility of that approach more
than anything.
bq. we call checkAccess() on an already prepared statement. Would have to add
another check to prepare() itself, which is a mess
Fair enough, I can buy that argument for not including it as of this v1. Even
though adding a check in prepare() feels hardly like a bit deal to me if I'm
being honest.
bq. This is just abuse of the authorization subsystem
I really fail to see how. Authorization is about allowing configurable limits
on what people can and cannot do and {{UNPREPARED_STATEMENTS}} fits that as
much as any other restriction we're discussing here as far as I can tell.
Granted, it's a restriction on query preparations instead of query execution,
but I don't see why limiting execution would be fine but limiting preparation
would be an horrible abuse of the system.
> Provide "strict mode" for CQL Queries
> -------------------------------------
>
> Key: CASSANDRA-8303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Anupam Arora
> Fix For: 3.0
>
>
> Please provide a "strict mode" option in cassandra that will kick out any CQL
> queries that are expensive, e.g. any query with ALLOWS FILTERING,
> multi-partition queries, secondary index queries, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
