[
https://issues.apache.org/jira/browse/CASSANDRA-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298775#comment-14298775
]
Sylvain Lebresne commented on CASSANDRA-8418:
---------------------------------------------
{quote}
unless we specify the query that should required {{ALLOW FILTERING}} in the
message, the warning is a bit useless.
documenting the change in the {{CHANGES.txt}} file for 3.0
{quote}
Why not have a warning that use whatever you planned to put in the
{{CHANGES.txt}} file? The goal is to make it more likely that user won't be
surprised of the change once they update to 3.0, and believe it or not, people
don't always read the changelog (not saying they always read their log btw,
that's why I'm advocating having the warning in multiple places). It's true
that without the query user will have a harder time finding out which queries
are responsible, but making them aware of the issue is still better than
nothing imo (note that we can absolutely link to this issue in the warning
message).
> 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)
