Thanks, yes, I was referring to the "compound columns" in this quote (from a previous thread):

"No CQL will never support super columns, but later versions (not 1.0.0)
will support compound columns.  Compound columns are better; instead of
a two-deep structure, you can have one of arbitrary depth."

I would like to design my keys to take advantage of this future development, when it comes.

On Thu, May 5, 2011 at 5:53 PM, Sylvain Lebresne <> wrote:
I suppose it depends what you are referring to by "compound columns".
If you're talking
about the CompositeType of CASSANDRA-2231 (which is my only guess), then the
format is in the javadoc and is:
* The encoding of a CompositeType column name should be:
*   <component><component><component> ...
* where <component> is:
*   <length of value><value><'end-of-component' byte>
* where the 'end-of-component' byte should always be 0 for actual column
* name.  However, it can set to 1 for query bounds. This allows to query for
* the equivalent of 'give me the full super-column'. That is, if during a
* slice query uses:
*   start = <3><"foo".getBytes()><0>
*   end   = <3><"foo".getBytes()><1>
* then he will be sure to get *all* the columns whose first component is "foo".
* If for a component, the 'end-of-component' is != 0, there should not be any
* following component.

I'll mention that this is not committed code yet (but soon hopefully
and the format
shouldn't change).


On Thu, May 5, 2011 at 4:44 PM, David Boxenhorn <> wrote:
> Is there a spec for compound columns?
> I want to know the exact format of compound columns so I can adhere to it.
> For example, what is the separator - or is some other format used (e.g.
> length:value or type:length:value)?