[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-dev
Subject:    =?UTF-8?Q?Re:=20Is=20SuperColumn=20necessary=3F?=
From:       "Stu Hood" <stu.hood () rackspace ! com>
Date:       2010-05-05 19:41:02
Message-ID: 1273088462.4839257 () 192 ! 168 ! 2 ! 229
[Download RAW message or body]

Hey Ed,

I've been working on a similar approach for arbitarily nested/compound column names \
in #998. See: http://github.com/stuhood/cassandra/blob/998/src/java/org/apache/cassandra/db/ColumnKey.java


The goal is to provide native support and potentially (in the very long term), API \
support for nested/compound names. The difference between our approaches boils down \
to needing to define a comparator for every level in #998, versus having dynamic \
types per name in your approach.

Thanks,
Stu


-----Original Message-----
From: "Ed Anuff" <ed@anuff.com>
Sent: Wednesday, May 5, 2010 1:31pm
To: user@cassandra.apache.org
Subject: Re: Is SuperColumn necessary?

Follow-up from last weeks discussion, I've been playing around with a simple
column comparator for composite column names that I put up on github.  I'd
be interested to hear what people think of this approach.

http://github.com/edanuff/CassandraCompositeType

Ed

On Wed, Apr 28, 2010 at 12:52 PM, Ed Anuff <ed@anuff.com> wrote:

> It might make sense to create a CompositeType subclass of AbstractType for
> the purpose of constructing and comparing these types of "composite" column
> names so that if you could more easily do that sort of thing rather than
> having to concatenate into one big string.
> 
> 
> On Wed, Apr 28, 2010 at 10:25 AM, Mike Malone <mike@simplegeo.com> wrote:
> 
> > The only thing SuperColumns appear to buy you (as someone pointed out to
> > me at the Cassandra meetup - I think it was Eric Florenzano) is that you can
> > use different comparator types for the Super/SubColumns, I guess..? But you
> > should be able to do the same thing by creating your own Column comparator.
> > I guess my point is that SuperColumns are mostly a convenience mechanism, as
> > far as I can tell.
> > 
> > Mike
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]