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 wrote:
> I mentioned a few limitations, so I'm not sure which you refer to.
>
>
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:
http://www.
Thank you for your detailed response!
On Jun 4, 2013 12:00 PM, "Shahab Yunus" 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 missing something
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 wrote:
> If
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[
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 see
