[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244011#comment-14244011
]
Sylvain Lebresne commented on CASSANDRA-8418:
---------------------------------------------
Let's try to focus here. The priority is that we should require {{ALLOW
FILTERING}} when we do filtering, and as that doesn't seem to be the case for
some query in 2.0/2.1, let's focus on how we fix that. The efficiency of the
filtering can be fixed later, especially since I doubt the double filtering is
terribly impactful.
Now, regarding queries that should require {{ALLOW FILTERING}} and don't, we
should probably be careful that adding it is a breaking change (even if it's a
bug fix). So my suggestion would be to let things as they are in 2.0, but log a
warning message if it's used. Changing it in 2.1 is probably fair game at this
point if we properly indicate it in the NEWS file.
> Queries that require allow filtering are working without it
> -----------------------------------------------------------
>
> Key: CASSANDRA-8418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8418
> Project: Cassandra
> Issue Type: Bug
> Reporter: Philip Thompson
> Assignee: Benjamin Lerer
> Priority: Minor
> Fix For: 3.0
>
> Attachments: CASSANDRA-8418.txt
>
>
> The trunk dtest {{cql_tests.py:TestCQL.composite_index_with_pk_test}} has
> begun failing after the changes to CASSANDRA-7981.
> With the schema {code}CREATE TABLE blogs (
> blog_id int,
> time1 int,
> time2 int,
> author text,
> content text,
> PRIMARY KEY (blog_id, time1, time2){code}
> and {code}CREATE INDEX ON blogs(author){code}, then the query
> {code}SELECT blog_id, content FROM blogs WHERE time1 > 0 AND
> author='foo'{code} now requires ALLOW FILTERING, but did not before the
> refactor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
