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 <sylv...@datastax.com>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). > > -- > Sylvain > > On Thu, May 5, 2011 at 4:44 PM, David Boxenhorn <da...@taotown.com> 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)? > > >
