[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234773#comment-14234773 ] 

Sylvain Lebresne commented on CASSANDRA-8424:
---------------------------------------------

This not a bug in that those are know to not be handled by the code. The reason (for the first query at least) is what I explained in CASSANDRA-6377: it's hard to do it without a good internal refactoring because of some silliness of the current internals. As it happens, we have CASSANDRA-8099 for such a refactoring, so this should be solved in 3.0, but it will have to wait on that.

The 2nd query, where the primary key is given in full, would be easier to deal with, but that would still also some special casing, and I'm not convinced that it's useful enough in practice that it's worth adding a special case just for that (but this should be handled without special casing post-CASSANDRA-8099).

> Collection filtering not working when using PK
> ----------------------------------------------
>
>                 Key: CASSANDRA-8424
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8424
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native protocol v3]
> Ubuntu 14.04.5 64-bit
>            Reporter: Lex Lythius
>            Assignee: Benjamin Lerer
>            Priority: Minor
>              Labels: collections
>
> I can do queries for collection keys/values as detailed in http://www.datastax.com/dev/blog/cql-in-2-1 without problems. Even without having a secondary index on the collection it will work (with {{ALLOW FILTERING}}) but only as long as the query is performed through a *secondary* index. If you go through PK it won't. Of course full-scan filtering query is not allowed.
> As an example, I created this table:
> {code:SQL}
> CREATE TABLE test.uloc9 (
>     usr int,
>     type int,
>     gb ascii,
>     gb_q ascii,
>     info map<ascii, text>,
>     lat float,
>     lng float,
>     q int,
>     traits set<ascii>,
>     ts timestamp,
>     PRIMARY KEY (usr, type)
> );
> CREATE INDEX uloc9_gb ON test.uloc9 (gb);
> CREATE INDEX uloc9_gb_q ON test.uloc9 (gb_q);
> CREATE INDEX uloc9_traits ON test.uloc9 (traits);
> {code}
> then added some data and queried:
> {code}
> cqlsh:test> select * from uloc9 where gb='/nw' and info contains 'argentina' allow filtering;
>  usr | type | gb  | gb_q  | info                                     | lat          | lng          | q | traits             | ts
> -----+------+-----+-------+------------------------------------------+--------------+--------------+---+--------------------+--------------------------
>    1 |    0 | /nw | /nw:1 | {'ci': 'san antonio', 'co': 'argentina'} | -40.74000168 | -65.80000305 | 1 | {'r:photographer'} | 2014-11-04 18:20:29-0300
>    1 |    1 | /nw | /nw:1 | {'ci': 'san antonio', 'co': 'argentina'} | -40.75799942 | -66.00800323 | 1 | {'r:photographer'} | 2014-11-04 18:20:29-0300
> (2 rows)
> cqlsh:test> select * from uloc9 where usr=1 and info contains 'argentina' allow filtering;
> code=2200 [Invalid query] message="No indexed columns present in by-columns clause with Equal operator"
> cqlsh:test> select * from uloc9 where usr=1 and type=0 and info contains 'argentina' allow filtering;
> code=2200 [Invalid query] message="No indexed columns present in by-columns clause with Equal operator"
> {code}
> Maybe I got things wrong, but I don't see any reasons why collection filtering should fail when using PK while it succeeds using any secondary index (related or otherwise).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)