You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/04/05 04:06:06 UTC

[jira] [Issue Comment Edited] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

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

Sylvain Lebresne edited comment on CASSANDRA-2231 at 4/5/11 2:04 AM:
---------------------------------------------------------------------

The thing is this, if we agree that for actual values, then end-of-component (eoc) is always 0, I don't see what could be the use for the start or end of a query to have anything after a eoc != 0, since for any comparison of the start (resp. end) with an actual value, the comparaison will return as soon as we compare that eoc.

Taking your example of start => (100+1): (10+0), when compared to any value (x:0):(y:0), the comparison will either return when comparing x to 100, and if x==100, will stop when comparing the eoc (returning then that start > value, so that query would typically return all value whose first component is strictly greater than 100).

      was (Author: slebresne):
    The thing is this, if we agree that for actual values, then end-of-component (eoc) is always 0, I don't see what could be the use for the start or end of a query to have anything after a eoc != 0, since for any comparison of the start (resp. end) with an actual value, the comparaison will return as soon as we compare that eoc.

Taking your example of start => (100+1):(10+0), when compared to any value (x:0):(y:0), the comparison will either return when comparing x to 100, and if x==100, will stop when comparing the eoc (returning then that start > value, so that query would typically return all value whose first component is strictly greater than 100).
  
> 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
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 0.7.5
>
>         Attachments: CompositeType-and-DynamicCompositeType.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