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 Wed, 02 Mar 2011 21:33:37 GMT


Ed Anuff commented on CASSANDRA-2231:

Ok, I'll let the "hacky" part slide. :)  Sylvain's approach is much more elegant in how it's
declared, and using the existing comparers is nice and something I did initially until I decided
I'd rather have everything under one roof for performance and maintainability as well as in
order to add some things to make queries easier.  So, I'm in agreement with the way he's proposing.

The central question here is does the final implementation provide sufficiently flexibility
for index building.  That's why a composite type is necessary.  I have similar concerns to
Todd, losing the dynamic capability is actually bit more of a problem the more I think about
it, I'd look to solve that in two ways (1) having validation only require that the components,
if they're provided, are of the correct type (looking at Sylvain's code, the compare function
should work, but the validation wouldn't), and (2) creating a DynamicType that could be used
for dynamic types.  Given that a number of the languages that are talking to Cassandra are
dynamic languages and even people using Java, like me, might be using JSON types, some form
of dynamic support is a good idea, but I'd be happy to separate that into a different comparator.
 My other concern is that one of the things that got stripped out was the MATCH_MINIMUM, MATCH_MAXIMUM
feature, which made implementing greater-than-equals, less-than-equals, etc. in ranges much
easier.  That might be the wrong place to implement that, though, and might be a bit of a

We've got somewhat of a challenge at the application tier, which we're seeing in the Hector
project, in terms of providing a uniform way to do the type of indexing needed for ORM, which
the current secondary indexes just don't satisfy.  The benefit of why we need a sufficiently
flexible composite mechanism in core is because we're already assuming the capability in order
to implement this stuff.  It doesn't have to be my code or my format, but it really should
meet the needs of the app builders.  Might a more forgiving version of Sylvain's CompositeType
plus a new DynamicType be the way to go?

> 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.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