Thanks Eric for the detailed explanation but can you point to a source or
document for this restriction in CQL3 tables? Doesn't it take away the main
feature of the NoSQL store? Or am I am missing something obvious here?
Regards,
Shahab
On Tue, Jun 4, 2013 at 2:12 PM, Eric Stevens <migh...@gmail.com> wrote:
> If this is a standard column family, not a CQL3 table, then using CQL3
> will not give you the results you expect.
>
> From cassandra-cli, let's set up some test data:
>
> [default@unknown] create keyspace test;
> [default@unknown] use test;
> [default@test] create column family test;
> [default@test] set test['a1']['c1'] = 'a1c1';
> [default@test] set test['a1']['c2'] = 'a1c2';
> [default@test] set test['a2']['c1'] = 'a2c1';
> [default@test] set test['a2']['c2'] = 'a2c2';
>
> Two rows with two columns each, right? Not as far as CQL3 is concerned:
>
> cqlsh> use test;
> cqlsh:test> select * from test;
>
> key | column1 | value
> -----+---------+--------
> a2 | 0xc1 | 0xa2c1
> a2 | 0xc2 | 0xa2c2
> a1 | 0xc1 | 0xa1c1
> a1 | 0xc2 | 0xa1c2
>
> Basically for CQL3, without the additional metadata and enforcement that
> is established by having created the column family as a CQL3 table, CQL
> will treat each key/column pair as a separate row for CQL purposes. This
> is most likely at least in part due to the fact that CQL3 tables *cannot
> have arbitrary columns *like standard column families can. It wouldn't
> know what columns are available for display. This also exposes some of the
> underlying structure behind CQL3 tables.
>
> CQL 3 is not reverse compatible with CQL 2 for most things. If you cannot
> migrate your data to a CQL3 table.
>
> The equivalent structure in CQL3 tables
>
> cqlsh:test> create table test3 (key text PRIMARY KEY, c1 text, c2 text);
> cqlsh:test> INSERT INTO test3(key, c1, c2) VALUES ('a1', 'a1c1', 'a1c2');
> cqlsh:test> INSERT INTO test3(key, c1, c2) VALUES ('a2', 'a2c1', 'a2c2');
> cqlsh:test> select * from test3;
>
> key | c1 | c2
> -----+------+------
> a2 | a2c1 | a2c2
> a1 | a1c1 | a1c2
>
> This comes with many important restrictions, one of which as mentioned is
> that you cannot have arbitrary columns in a CQL3 table, just like you
> cannot in a traditional relational database. Likewise you cannot use
> traditional approaches to populating data into a CQL3 table:
>
> [default@test] get test3['a1'];
> test3 not found in current keyspace.
> [default@test] set test3['a3']['c1'] = 'a3c1';
> test3 not found in current keyspace.
> [default@test] describe test3;
> WARNING: CQL3 tables are intentionally omitted from 'describe' output.
>
>
>
>
> On Tue, Jun 4, 2013 at 12:56 PM, ekaqu something <ekaqu1...@gmail.com>wrote:
>
>> I run a 1.1 cluster and currently testing out a 1.2 cluster. I have
>> noticed that with 1.2 it switched to CQL3 which is acting differently than
>> I would expect. When I do "select key from \"cf\";" I get many many
>> duplicate keys. When I did the same with CQL 2 I only get the keys
>> defined. This seems to also be the case for count(*), in cql2 it would
>> return the number of keys i have, in 3 it returns way more than i really
>> have.
>>
>> $ cqlsh `hostname` <<EOF
>> use keyspace;
>> select count(*) from "cf";
>> EOF
>>
>>
>> count
>> -------
>> 10000
>>
>> Default LIMIT of 10000 was used. Specify your own LIMIT clause to get
>> more results.
>>
>> $ cqlsh `hostname` -3 <<EOF
>> use keyspace;
>> select count(*) from "cf";
>> EOF
>>
>>
>> count
>> -------
>> 10000
>>
>> Default LIMIT of 10000 was used. Specify your own LIMIT clause to get
>> more results.
>>
>>
>> $ cqlsh `hostname` -2 <<EOF
>> use keyspace;
>> select count(*) from cf;
>> EOF
>>
>>
>> count
>> -------
>> 1934
>>
>> 1934 rows have really been inserted. Is there something up with cql3 or
>> is there something else going on?
>>
>> Thanks for your time reading this email.
>>
>
>
