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 2014/02/27 13:34:21 UTC

[jira] [Created] (CASSANDRA-6778) FBUtilities.singleton() should use the CF comparator

Sylvain Lebresne created CASSANDRA-6778:
-------------------------------------------

             Summary: FBUtilities.singleton() should use the CF comparator
                 Key: CASSANDRA-6778
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6778
             Project: Cassandra
          Issue Type: Bug
            Reporter: Sylvain Lebresne
            Assignee: Sylvain Lebresne
             Fix For: 2.0.6


We sometimes use FBUtilities.singleton() to created a SortedSet for NamesQueryFilter. However, the set created by that method does not use the CF comparator, so that it use ByteBuffer comparison/equality for methods like contains(). And this might not be ok if it turns that the comparator is so that 2 column name can be equal without their binary representation being equal, and as it turns out at least IntegerType, DecimalType (because they let you put arbitrary many zeros in front of the binary encoding) have such property (BooleanType should also have that property though it doesn't in practice which I think that's a bug, but that's for another ticket).

I'll note that CASSANDRA-6733 contains an example where this matter.  However, in practice, only SELECT on compact tables that select just one column can ever ran into that and you'd only run into it if your client insert useless zeros in its IntegerType/DecimalType binary representation, which ought to be not common in the first place. It's still wrong and should be fixed.

Patch attached to include the comparator in FBUtilities.singleton. I also found 2 other small places where we were using ByteBuffer.equals() where the comparator should be used instead and attaching a 2nd patch for those.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)