Hi Christian, First of all I must say I am not a Cassandra user, but I will tell details I found. I hope some of them would be useful.
> - Gora keys are mapped to C* partition keys only I admit I don't have much knowledge about, so I have to look what is that of the partition keys :( > - Gora requires the C* ByteOrderedPartitioner Same as last question :( > - Comparators are always BYTESTYPE I think I read about this somewhere hardcoded, yes. > - Gora makes extensive use of super column families True. If I am not wrong, It is discouraged since are deprecated. But at this time we have to maintain compatibility at least until Gora 1.0. > - The implementation has a hard-coded replication factor of 1 This could be improved in properties.I think I saw some ticket suggesting that possibility of configuration, but my memory is not much reliable. > - Gora doesn't seem to take advantage of native column ordering in C* I guess does not take advantage. (A) > - Gora doesn't seem to utilize C* compound primary keys No, does not use them. (B) > - Gora doesn't seem to allow the use of per-operation consistency levels I never heard about this. Interesting. I thought it was consistency globally. (C) > Any pointers or upcoming discussions are appreciated. It seems you have been checking the code (it's a hard work). Thank you:) For (A),(B) and (C) must understand that Gora at this moment is an abstraction layer which allows changing backends. I personally will appreciate ideas about features that will be in accordance with the semantics involving the other datastores. At this moment what is completely possible is adding configuration options. Seems you have experience with Cassandra, so your comments will be much useful. For example, why do you need compound keys. It could be possible to add as feature and simulate in other datastores. This is my opinion, of course. I will be looking forward your comments. Regards, Alfonso Nishikawa
