[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001656#comment-13001656
]
Todd Nine commented on CASSANDRA-2231:
--------------------------------------
I do see your point. However, as a user and a developer of a JPA plugin take
this use case for an example of our requriements
Entities: User -> Vehicles
A User has a collection of vehicles. These can be ordered in several ways.
For this example, lets say by time created and name. This would lead to
several different column comparators. For properties on the user, first name,
last name, these would be UTF8 columns, for the collections, these would be
composite. I would end up with columns of the following definitions to allow
us to quickly load or them.
UTF8(firstname):value
UTF8(lastname):value
UTF8(vehicletime) LONG(vehicleTime) TIMEUUID(VEHICLEID) UTF8(VehicleProp) :
value
UTF8(vehiclename) UTF8(vehicleName) TIMEUUID(VEHICLEID) UTF8(VehicpeProp) :
value
In the event we move this index to an external CF, we lose the serialization
scope and guaranteed atomic write of using a single row key during a mutation.
While this is a separate issue as on Cassandra in general, we do need the
ability to work around this until serialization scope can extend over multiple
rows. Without this, to ensure that "lost writes" don't occur on indexing, a
user would need to introduce an extra system such as Zookeeper.
https://issues.apache.org/jira/browse/CASSANDRA-1684
> 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
