CQL maps a series of logical rows into a single physical row by transposing
multiple rows based on partition and clustering keys into slices of a row.
The point is to add a loose schema on top of a wide row which allows you
to stop reimplementing common patterns.
Yes, you can go in and mess with
"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:
"COMPACT STORAGE imposes the limit that you can't add columns to your
tables."
I was demonstrating you are i
From the Cassandra 1.2 Manual:
Using the compact storage directive prevents you from adding more than
one column that is not part of
the PRIMARY KEY.
At this time, updates to data in a table created with compact storage
are not allowed. The table with
compact storage that uses a compound prim
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 str
"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
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 wrote:
> On Wed, J
On Wed, Jul 31, 2013 at 3:10 PM, Jonathan Haddad 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.
[1] Use CQL3 non-COMPACT STORAGE if you want to, but there are also
I am glad this document helped you.
I like to point to this 'thrift-to-cql' document, since it was really
useful to me when I found it, even if I had to read it at least 3 times
entirely and still need to refer to some piece of it sometimes because of
the complexity of what is explained in it.
@S
On Wed, Jul 31, 2013 at 03:10:54PM -0700, Jonathan Haddad wrote:
>It's advised you do not use compact storage, as it's primarily for
>backwards compatibility.
Yes indeed, I understand what it does and why now, but only because
I was pointed to the thrift-to-cql document. The CQL documentat
It's advised you do not use compact storage, as it's primarily for
backwards compatibility.
The first of these option is COMPACT STORAGE. This option is meanly
targeted towards backward compatibility with some table definition created
before CQL3. But it also provides a slightly more compact layou
You should also profile what your data looks like on disk before picking a
format. It may not be as efficient to use one form or the other due to
extra disk overhead.
On Wed, Jul 31, 2013 at 1:32 PM, Jon Ribbens <
jon-cassan...@unequivocal.co.uk> wrote:
> On Wed, Jul 31, 2013 at 02:21:52PM +0200
On Wed, Jul 31, 2013 at 02:21:52PM +0200, Alain RODRIGUEZ wrote:
>I like to point to this article from Sylvain, which is really well
>written.
>http://www.datastax.com/dev/blog/thrift-to-cql3
Ah, thankyou, it looks like a combination of multi-column "PRIMARY KEY"
and use of collections
Oops, sorry about double post.
Alain
2013/7/31 Alain RODRIGUEZ
> I like to point to this article from Sylvain, which is really well written.
>
> http://www.datastax.com/dev/blog/thrift-to-cql3
>
> It explains a lot of things and is really interesting for Cassandra users
> pre-CQL3.
>
> Actuall
I like to point to this article from Sylvain, which is really well written.
http://www.datastax.com/dev/blog/thrift-to-cql3
It explains a lot of things and is really interesting for Cassandra users
pre-CQL3.
Actually, old dynamic columns were defined this way :
CREATE TABLE test (
key
Basically add a column to ypur primary key called name which is a string
and a column named value ttyped bytes. Or a map of byte bye named extra, or
just use compact storage lile i do.
On Wednesday, July 31, 2013, Jon Ribbens
wrote:
> I thought that part of the point of Cassandra was that, unlike
I thought that part of the point of Cassandra was that, unlike a
standard relational database, each row does not have to have the same
set of columns. I don't understand how this squares with CQL. If I want
to have a table ("column family"?) with a few fixed columns that are
relevant to every row,
16 matches
Mail list logo
