I wrote libQtCassandra and the current version does not support super-columns. One reason for not adding that support has been that it breaks the scheme used by the library to give users a way to use the array operator ([]) to access and write the data.
If you're not familiar, the library let's you create a "context" (a connection to a Cassandra cluster) and from that context you can write something like this:
// set value 123 in "column name" of "row key" of "column family":
context["column family"]["row key"]["column name"] = 123;
// retrieve that value:
int value = context["column family"]["row key"]["column name"];
So... very simple. However, if we introduce super-columns, we add one more array access which depends on whether there is a super-column or not. What would you do?
Would you use a function to access super columns?
context["column family"]["row key"].sc("super column")["column name"] = 123;
Or would you make the super column work seamlessly like the other parameters?
context["column family"]["row key"]["super column"]["column name"] = 123;
Obviously the system (column family) knows what's what. So it is easy to implement it either way, only it makes the library quite a bit more complicated to support the array syntax for super-columns.
I had another idea which was to add an object that could be used when specifying the row. But that looks rather ugly:
context["column family"][sc("row key", "super column")]["column name"] = 123;
This is easier to implement but doesn't look too good when you look at final code.
What would be a more stl or boost like approach to such a problem?
Seems like introducing supercolumn support would only continue to encourage the use of a deprecated feature. Use of alternatives such as composites are a better approach to solving problems that push people toward supercolumns. I'm not sure the effort wouldn't actually be a movement in the wrong direction. In the meantime, if people MUST access supercolumns from a C++ app, they can do so using Thrift.
So my suggestion would be to discuss a way to add composite support in libQtCassandra, since it doesn't appear to be there at the moment. This way we encourage users to make wiser data model choices by providing easier access to the correct constructs.