"Feel free to continue to use thrift's wide row structure, with ad hoc columns. No one is stopping you."
Thanks. I was not trying to stop you from doing it your way either.
You said this:I was demonstrating you are incorrect.
"COMPACT STORAGE imposes the limit that you can't add columns to your tables."I then went on to point out that Cassandra is a ColumnFamily data store which was designed around big table. You could always add column dynamically because schema-less is one of the key components of a ColumnFamily datastore.I know which CQL document you are loosely referencing that implies you can not add columns to compact storage. If that were true Cassandra would have never been a ColumnFamily data store.
I have found several documents which are championing CQL and its constructs, which suggest that some thing can not be done with compact storage. In reality those are short comings of the CQL language. I say this because the language can not easily accommodate the original schema system.Many applications that are already written and performing well do NOT fit well into the CQL model of non compact storage (which does not have a name by the way probably because the opposite of compact is sparse and how would "SPARSE STORAGE" sound?). Implying all the original stuff is "legacy" and you "should probably avoid it" is wrong.In many cases compact storage it is the best way to store things, because it is the smallest.
On Mon, Aug 5, 2013 at 4:57 PM, Jonathan Haddad <email@example.com> wrote:
If you expected your CQL3 query to work, then I think you've missed the point of CQL completely. For many of us, adding in a query layer which gives us predictable column names, but continues to allow us to utilize wide rows on disk is a huge benefit. Why would I want to reinvent a system for structured data when the DB can handle it for me? I get a bunch of stuff for free with CQL, which decreases my development time, which is the resource that I happen to be the most bottlenecked on.Feel free to continue to use thrift's wide row structure, with ad hoc columns. No one is stopping you.On Mon, Aug 5, 2013 at 1:36 PM, Edward Capriolo <firstname.lastname@example.org> wrote:
"COMPACT STORAGE imposes the limit that you can't add columns to your tables."
Is absolutely false. If anything CQL is imposing the limits!
Simple to prove. Try something like this:
create table abc (x int);
insert into abc (y) values (5);
and watch CQL reject the insert saying something to the effect of 'y? whats that? Did you mean CQL2 OR 1.5?, or hamburgers'
Then go to the Cassandra cli and do this:
create column family abd;
set ['abd']['y']= '5';
set ['abd']['z']='4';AND IT WORKS!
I noticed the nomenclature starting to spring up around the term "legacy tables" and docs based around "can't do with them". Frankly it makes me nuts because...
This little known web company named google produced a white paper about what a ColumnFamily data model could do http://en.wikipedia.org/wiki/BigTable . Cassandra was build on the BigTable/ColumnFamily data model. There was also this big movement called NoSQL, where people wanted to break free of query languages and rigid schema's....
On Mon, Aug 5, 2013 at 1:56 PM, Jonathan Haddad <email@example.com> wrote:
The CQL docs recommend not using it - I didn't just make that up. :) COMPACT STORAGE imposes the limit that you can't add columns to your tables. For those of us that are heavy CQL users, this limitation is a total deal breaker.On Mon, Aug 5, 2013 at 10:27 AM, Robert Coli <firstname.lastname@example.org> wrote:
On Wed, Jul 31, 2013 at 3:10 PM, Jonathan Haddad <email@example.com> wrote:
It's advised you do not use compact storage, as it's primarily for backwards compatibility.Many Apache Cassandra experts do not advise against using COMPACT STORAGE.  Use CQL3 non-COMPACT STORAGE if you want to, but there are also valid reasons to not use it. Asserting that there is some good reason you should not use COMPACT STORAGE (other than range ghosts?) seems inaccurate. :)=Rob--