"By no upgrade path" I mean to say if I have a table with compact storage I
can not upgrade it to sparse storage. If i have an existing COMPACT table
and I want to add a Map to it, I can not. This is what I mean by no upgrade
path.
Column families that mix static and dynamic columns are pretty common. In
fact it is pretty much the default case, you have a default validator then
some columns have specific validators. In the old days people used to say
"You only need one column family" you would subdivide your row key into
parts username=username, password=password, friend-friene = friends,
pet-pets = pets. It's very efficient and very easy if you understand what a
slice is. Is everyone else just adding a column family every time they have
new data? :) Sounds very un-no-sql-like.
Most people are probably going to store column names as tersely as
possible. Your not going to store "password" as a multibyte
UTF8("password"). You store it as ascii("password"). (or really ascii('pw')
Also for the rest of my comment I meant that the comparator of any sparse
tables always seems to be a COMPOSITE even if it is only one part (last I
checked). Everything is -COMPOSITE(UTF-8(colname))- at minimum, when in a
compact table it is -colname-
My overarching point is the 5 things I listed do have a cost, the user by
default gets sparse storage unless they are smart enough to know they do
not want it. This is naturally going to force people away from compact
storage.
Basically for any column family: two possible decision paths:
1) use compact
2) use sparse
Other then ease of use why would I chose sparse? Why should it be the
default?
On Wed, Jan 9, 2013 at 5:14 PM, Sylvain Lebresne <sylv...@datastax.com>wrote:
> c way. Now I can't pretend knowing what every user is doing, but from
> my experience and what I've seen, this is not such a common thing and CF
> are
> either static or dynamic in nature, not both.
>
