Nice, Ed, we're doing something very similar but less generic.
Now replace all of the various methods for querying with a simple query
interface that takes a Predicate, allow the user to specify (in
storage-conf) which levels of the nested Columns should be indexed, and
completely remove Comparators and have people subclass Column / implement
IColumn and we'd really be on to something ;).
Mock storage-conf.xml:
<Column Name="ThingThatsNowKey" Indexed="True" ClusterPartitioned="True"
Type="UTF8">
<Column Name="ThingThatsNowColumnFamily" DiskPartitioned="True"
Type="UTF8">
<Column Name="ThingThatsNowSuperColumnName" Type="Long">
<Column Name="ThingThatsNowColumnName" Indexed="True" Type="ASCII">
<Column Name="ThingThatCantCurrentlyBeRepresented"/>
</Column>
</Column>
</Column>
</Column>
Thrift:
struct NamePredicate {
1: required list<binary> column_names,
}
struct SlicePredicate {
1: required binary start,
2: required binary end,
}
struct CountPredicate {
1: required struct predicate,
2: required i32 count=100,
}
struct AndPredicate {
1: required Predicate left,
2: required Predicate right,
}
struct SubColumnsPredicate {
1: required Predicate columns,
2: required Predicate subcolumns,
}
... OrPredicate, OtherUsefulPredicates ...
query(predicate, count, consistency_level) # Count here would be total
count of leaf values returned, whereas CountPredicate specifies a column
count for a particular sub-slice.
Not fully baked... but I think this could really simplify stuff and make it
more flexible. Downside is it may give people enough rope to hang
themselves, but at least the predicate stuff is easily distributable.
I'm thinking I'll play around with implementing some of this stuff myself if
I have any free time in the near future.
Mike
On Wed, May 5, 2010 at 2:04 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
> Very interesting, thanks!
>
> On Wed, May 5, 2010 at 1:31 PM, Ed Anuff <e...@anuff.com> wrote:
> > 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 <e...@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 <m...@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
> >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>
