Yes, the "column" here is not appropriate.
Maybe we need not to create new terms, in Google's Bigtable, the term
"qualifier" is a good one.
On Thu, May 6, 2010 at 3:04 PM, David Boxenhorn <da...@lookin2.com> wrote:
> That would be a good time to get rid of the confusing "column" term, which
> incorrectly suggests a two-dimensional tabular structure.
>
> Suggestions:
>
> 1. A hypercube (or hypocube, if only two dimensions): replace "key" and
> "column" with "1st dimension", "2nd dimension", etc.
>
> 2. A file system: replace "key" and "column" with "directory" and
> "subdirectory"
>
> 3. A tuple tree: "Column family" replaced by top-level tuple, whose value
> is the set of keys, whose value is the set of supercolumns of the key, whose
> value is the set of columns for the supercolumn, etc.
>
> 4. Etc.
>
> On Thu, May 6, 2010 at 2:28 AM, Mike Malone <m...@simplegeo.com> wrote:
>
>> 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
>>>
>>
>>
>
