2

Basically here is how my table is set up:

CREATE TABLE points (
  name ascii,
  id varint,
  attributes map<ascii, ascii>,
  PRIMARY KEY (name, id)
)

and if I run the following SELECT statement I get this returned:

SELECT id, attributes from points limit 5;

   id | attributes
  ----+------------------------------------------
    1 | {STATION/Name: ABC, Type: 2, pFreq: 101}
    2 | {STATION/Name: ABC, Type: 1, pFreq: 101}
    3 | {STATION/Name: DEF, Type: 1, pFreq: 103}
    4 | {STATION/Name: GHI, Type: 2, pFreq: 105}
    5 | {STATION/Name: GHI, Type: 1, pFreq: 105}

What I would like to do is be able to form a WHERE clause based on info inside of attributes. Something like the following statement:

SELECT id FROM points WHERE name = 'NAME' AND attributes['pFreq'] = 101;

However, when I run this I get the following error:

Bad Request: line 1:56 no viable alternative at input '['

I looked at this discussion and it seems as though it is not supported yet, is this true? Or is there a way to filter on the attributes information?

Here are the versions I am working with:

[cqlsh 4.1.1 | Cassandra 2.0.7 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
iso_spitfire
  • 23
  • 3

1 Answers1

1

Yes is true, instead you can use CONTAINS:

SELECT * FROM points WHERE attributes CONTAINS 101;
Aaron
  • 55,518
  • 11
  • 116
  • 132
Makoton
  • 443
  • 3
  • 14
  • When I use CONTAINS I get the following error: Bad Request: line 1:104 no viable alternative at input 'CONTAINS' – iso_spitfire Jul 01 '15 at 21:30
  • can you use map instead of ascii?, or is mandatory use ascii? – Makoton Jul 01 '15 at 21:34
  • create index on points (attributes) returns "Bad Request: Indexes on collections are no yet supported". So this seems like the root of my problems. Not sure if there is a workaround for it at all, outside of splitting pFreq out into its own part of the schema. – iso_spitfire Jul 01 '15 at 21:45
  • 1
    Can you upgrade your cassandra version to cassandra greather than 2.1?? I created a index in dsc-cassandra-2.1.4, and works fine – Makoton Jul 01 '15 at 21:59
  • Thats up to my developers I suppose, lol. But thanks for the info. I don't know why they would schema tables in such a way we can't read items before the capability exists. Oh well! – iso_spitfire Jul 02 '15 at 14:58