[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK
[
https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592633#comment-14592633
]
Georg Koester commented on CASSANDRA-8424:
--
What about this:
{code}
select * from uloc9 where usr = 1 and type in (:types)
{code}
I get on a similar query the following error:
{code}
Cannot restrict column type by IN relation as a collection is selected by the
query
{code}
Should I create a different bug for this problem?
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
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 mapascii, text,
lat float,
lng float,
q int,
traits setascii,
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.8305 | 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)
[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK
[
https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235540#comment-14235540
]
Lex Lythius commented on CASSANDRA-8424:
Thanks for the explanation, Sylvain. I'll wait for 3.0 then.
Just so that this doesn't get overlooked when refactoring takes place, I added
the corresponding #8099 blocks #8424 link.
Cheers!
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
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 mapascii, text,
lat float,
lng float,
q int,
traits setascii,
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.8305 | 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)
[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK
[
https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 mapascii, text,
lat float,
lng float,
q int,
traits setascii,
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.8305 | 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)
[jira] [Commented] (CASSANDRA-8424) Collection filtering not working when using PK
[
https://issues.apache.org/jira/browse/CASSANDRA-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234776#comment-14234776
]
Sylvain Lebresne commented on CASSANDRA-8424:
-
Or to sum up what's up, I don't think the added complexity of adding this on
top of the current code is worth the benefits, and I suggest just waiting on
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
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 mapascii, text,
lat float,
lng float,
q int,
traits setascii,
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.8305 | 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)
