[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008459#comment-13008459
]
Sylvain Lebresne commented on CASSANDRA-2231:
---------------------------------------------
That would be better solved by having reversed comparator for all comparators,
and I would much prefer a general way to define a reversed comparator. That
is, for instance, you could declare comparator=LongType(order=desc). Having a
way That would be better solved by having reversed comparator for all
comparators, and I would much prefer having a general way to define a reversed
comparator. That is, for instance, you could declare
{{comparator=LongType(order=desc)}}.
That way you don't have to mess with the composite types encoded format (and
I'm really keen on keeping it as simple as possible). Plus have a reversed
comparator for all comparator is generally useful even outside composite types
(granted it's a bit less useful for simple types since you can always query in
reverse, but reverse queries are probably a bit slower due to reverse seeks).
Even more generally, I think being able to parametrize the behavior of
comparators is genuinely useful. For instance, I could see having only one
comparator for UUIDs (in the spirit of CASSANDRA-2233) and being able to say
stuffs like
{noformat}
comparator=UUIDType // accepts both time based and lexical
comparator=UUIDType(restrictTo=time) // time based only
comparator=UUIDType(restrictTo=lexical) // lexical only
{noformat}
or something along those lines.
I've opened CASSANDRA-2355 for doing the reverse part of this.
> Add CompositeType comparer to the comparers provided in
> org.apache.cassandra.db.marshal
> ---------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> 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, edanuff-CassandraCompositeType-1e253c4.zip
>
>
> 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:
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for
> contribution is attached and has been previously maintained on github here:
> https://github.com/edanuff/CassandraCompositeType
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
