[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002193#comment-13002193
 ] 

Sylvain Lebresne commented on CASSANDRA-2231:
---------------------------------------------

We could do that. But I have to admit that I'm usually not very fond of making 
things work when it's not clear they should. I think that could hide problems 
more than it helps. Better fail fast if there is a mess up.

And if you want to store in the same row column names that have intrinsically 
different structures, you can prefix it manually to distinguish thinks. That 
is, in you example, you'll replace <integer,uuid,timestamp> (type1) by 
<integer,integer,uuid,timestamp> and <string,uuid,timestamp> (type2) by 
<integer,string,uuid,timestamp> and assign the same integer for all the column 
name of type1 and the same integer (but a different from first one) to all 
those of type2. And this has actually a bunch of advantages: because you use a 
true component, you can query for the whole range of column name having the 
same 'type' (aka all type1 or all type2). Moreover you do control the prefix so 
you have more control on how each separate set of columns sort between each 
other. Yes you have to manage those prefix client side, but honestly I think 
it's a small price for the type safety it provides.


> 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

        

Reply via email to