cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Anuff (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
Date Thu, 03 Mar 2011 19:12:37 GMT


Ed Anuff commented on CASSANDRA-2231:

bq.Greater-than is already doable in my previous patch (up to the bug in validation). For
the less-than part, I agree that it is nice to be able to do it easily. In my new patch, I
add a leading byte to each component, whose purpose is to always be 0, except for lesser-than
query. That way, you can do the query above easily. The price is a slightly more complicated
encoding but I think it's totally worth it.

Just to be clear, the original idea was to make it possible to construct a key for the purposes
of doing a range slice that would compare inclusive either or both at the start and finish
of the range.  This appears to be possible with the "inclusion byte" that you're using in
lines 179 through 184 of your patch.  Is that correct?

> Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
> ---------------------------------------------------------------------------------------
>                 Key: CASSANDRA-2231
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Contrib
>    Affects Versions: 0.7.3
>            Reporter: Ed Anuff
>            Priority: Minor
>         Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 0001-Add-compositeType.patch,
> CompositeType is a custom comparer that makes it possible to create comparable composite
values out of the basic types that Cassandra currently supports, such as Long, UUID, etc.
 This is very useful in both the creation of custom inverted indexes using columns in a skinny
row, where each column name is a composite value, and also when using Cassandra's built-in
secondary index support, where it can be used to encode the values in the columns that Cassandra
indexes.  One scenario for the usage of these is documented here:
 Source for contribution is attached and has been previously maintained on github here:

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message