the example you provided does not work for for my use case.
CREATE TABLE t (
key blob,
static my_static_column_1 int,
static my_static_column_2 float,
static my_static_column_3 blob,
....,
dynamic_column_name blob,
dynamic_column_value blob,
PRIMARY KEY (key, dynamic_column_name);
)
the dynamic column can't be part of the primary key. The temporal entity
key can be the default UUID or the user can choose the field in their
object. Within our framework, we have concept of temporal links between one
or more temporal entities. Poluting the primary key with the dynamic column
wouldn't work.
Please excuse the confusing RDB comparison. My point is that Cassandra's
dynamic column feature is the "unique" feature that makes it better than
traditional RDB or newSql like VoltDB for building temporal databases. With
databases that require static schema + alter table for managing schema
evolution, it makes it harder and results in down time.
One of the challenges of data management over time is evolving the data
model and making queries simple. If the record is 5 years old, it probably
has a difference schema than a record inserted this week. With temporal
databases, every update is an insert, so it's a little bit more complex
than just "use a blob". There's a whole level of complication with temporal
data and CQL3 custom types isn't clear to me. I've read the CQL3
documentation on the custom types several times and it is rather poor. It
gives me the impression there's still work needed to get custom types in
good shape.
With regard to examples others have told me, your advice is fair. A few
minutes with google and some blogs should pop up. The reason I bring these
things up isn't to put down CQL. It's because I care and want to help
improve Cassandra by sharing my experience. I consistently recommend new
users learn and understand both Thrift and CQL.
On Wed, Jan 21, 2015 at 11:45 AM, Sylvain Lebresne <sylv...@datastax.com>
wrote:
> On Wed, Jan 21, 2015 at 4:44 PM, Peter Lin <wool...@gmail.com> wrote:
>
>> I don't remember other people's examples in detail due to my shitty
>> memory, so I'd rather not misquote.
>>
>
> Fair enough, but maybe you shouldn't use "people's examples you don't
> remenber" as argument then. Those examples might be wrong or outdated and
> that kind of stuff creates confusion for everyone.
>
>
>>
>> In my case, I mix static and dynamic columns in a single column family
>> with primitives and objects. The objects are temporal object graphs with a
>> known type. Doing this type of stuff is basically transparent for me, since
>> I'm using thrift and our data modeler generates helper classes. Our tooling
>> seamlessly convert the bytes back to the target object. We have a few
>> standard static columns related to temporal metadata. At any time, dynamic
>> columns can be added and they can be primitives or objects.
>>
>
> I don't see anything in that that cannot be done with CQL. You can mix
> static and dynamic columns in CQL thanks to static columns. More precisely,
> you can do what you're describing with a table looking a bit like this:
> CREATE TABLE t (
> key blob,
> static my_static_column_1 int,
> static my_static_column_2 float,
> static my_static_column_3 blob,
> ....,
> dynamic_column_name blob,
> dynamic_column_value blob,
> PRIMARY KEY (key, dynamic_column_name);
> )
>
> And your helper classes will serialize your objects as they probably do
> today (if you use a custom comparator, you can do that too). And let it be
> clear that I'm not pretending that doing it this way is tremendously
> simpler than thrift. But I'm saying that 1) it's possible and 2) while it's
> not meaningfully simpler than thriftMy , it's not really harder either (and
> in fact, it's actually less verbose with CQL than with raw thrift).
>
>
>>
>> For the record, doing this kind of stuff in a relational database sucks
>> horribly.
>>
>
> I don't know what that has to do with CQL to be honest. If you're doing
> relational with CQL you're doing it wrong. And please note that I'm not
> saying CQL is the perfect API for modeling temporal data. But I don't get
> how thrift, which is very crude API, is a much better API at that than CQL
> (or, again, how it allows you to do things you can't with CQL).
>
> --
> Sylvain
>
