[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001770#comment-13001770
]
Todd Nine commented on CASSANDRA-2231:
--------------------------------------
As per Ed's previous comment. I use over 30 different indexing schemes on our
data currently in my JDO code. The ultimate goal for this feature is to
support the implementation of a JPA framework that works similarly to GAE.
Having the ability to build the indexes that a user specifies without
dynamically creating CFs is a must have for us. There are a lot of issues
surrounding the complexity of building the index itself in the plugin that are
outside the scope of this issue. However we don't really have a comparator
mechanism to support these types of indexes.
In all use cases we defined, our searches and therefore indexes need an order
by clause as well as a query criteria to support the paging that most
applications will require. This order could simply be a natural ordering of
entity keys, or it could be on specific properties of the related entity. As
applications grow in size, so will the complexity and number of indexes to
support it, I'm concerned creating this many CFs could cause serious issues.
This doesn't have to be a well advertised feature for the end user to create
CFs with, but I feel very strongly that a dynamic type for CF's is a must in
order to proceed with the JPA plugin we've been designing.
> 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
