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