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 Fri, 18 Mar 2011 16:38:29 GMT


Ed Anuff commented on CASSANDRA-2231:

For parameterized behavior of comparators, my assumption is that this would work within the
DynamicCompositeType as well?  I'll add this to Cassandra-2235, but I'm thinking about the
embedded comparator names in the dynamic format.  Right now, you're simply calling FBUtilities.getComparator()
with the name, but ultimately we'd need a more robust comparator factory that could be passed
something like "UUIDType(restrictTo=time,sort=desc)" and parse out the parameters in order
to construct the instance and was able to cache the parameterized version in a similar way
to how your patch currently caches the comparators it instantiates, and would probably need
to be able to know that "UUIDType(restrictTo=time,sort=desc)" and "UUIDType(sort=desc,restrictTo=time)"
are the same comparator.

> 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
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 0.7.5
>         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