[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001671#comment-13001671
]
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 hack.
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: 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.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
