I mentioned a few limitations, so I'm not sure which you refer to.
As for not being able to access a CQL3 column family via traditional
approaches, beyond the example I gave above (where cassandra-cli claims it
does not recognize the column family), here is an article that mentions it:
Thanks Eric. Yeah, I was asking about the second limitation (about dynamic
columns) and you have explained it well along with pointers to read further.
Regards,
Shahab
On Wed, Jun 5, 2013 at 8:18 AM, Eric Stevens migh...@gmail.com wrote:
I mentioned a few limitations, so I'm not sure which
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
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
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
Thank you for your detailed response!
On Jun 4, 2013 12:00 PM, Shahab Yunus shahab.yu...@gmail.com wrote:
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
