cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Anuff (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
Date Mon, 04 Apr 2011 04:38:05 GMT


Ed Anuff commented on CASSANDRA-2231:

One more thing that's come up in testing, we're finding that only the last end-of-component
byte is allowed to be non-zero.  In lines 231-233 of your path, you do this check in AbstractCompositeType.validate():

+            byte b = bb.get();
+            if (b != 0 && bb.remaining() != 0)
+                throw new MarshalException("Invalid bytes remaining after an end-of-component
at component" + i);

Is this check necessary or would it be ok if the end-of-component byte could be non-zero in
any component?  We're usually doing the less-than-equals or greater-than-equals comparisons
on the first component value, not the last, which is usually just a discriminator value to
prevent duplicate column names.

> Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
> ---------------------------------------------------------------------------------------
>                 Key: CASSANDRA-2231
>                 URL:
>             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,
> 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:
 Source for contribution is attached and has been previously maintained on github here:

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message