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/05/16 13:25:03 UTC

[jira] [Commented] (CASSANDRA-6950) Secondary index query fails with tc range query when ordered by DESC

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

Sylvain Lebresne commented on CASSANDRA-6950:
---------------------------------------------

bq. Actually, I think that would fix thrift, because the current behavior could be considered wrong.

Well this is the whole question, what behavior is right for thrift :). In thrift we never (to the best of my knowledge) special case code for a specific AbstractType, and starting doing so now in that case makes me slightly uncomfortable. In particular, the order  in thrift is so far always directly the one of said AbstractType. So does it makes more sense to ignore ReverseType as defaultValidator/column validator or not, I'm not sure (and I don't think there is an absolute "right" answer) but doing so would risk breaking user that rely on the current behavior (that has been here basically forever). I'd agree though that using ReversedType for a validator is somewhat whack and probably almost no-one does that, but I'll admit that I'm leaning towards keeping things the way it is as far as thrift goes just in case someone relies on it (and if someone using this is bugged by this, he can easily remove the ReversedType use). I don't feel extremely strongly though, if we prefer going with changing thrift too, I'll just blame it on you if some user complains that we've break his code in a minor release :).

> Secondary index query fails with tc range query when ordered by DESC
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-6950
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6950
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: RHEL 6.3 virtual guest, apache-cassandra-2.0.6-SNAPSHOT-src.tar.gz from build #284 (also tried with 2.0.5 with CASSANDRA-6666 patch custom-applied with same result).
>            Reporter: Andre Campeau
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0.8
>
>         Attachments: 6950-pycassa-repro.py, 6950.txt
>
>
>     create table test4 ( name text, lname text, tc bigint, record text, PRIMARY KEY ((name, lname), tc)) WITH CLUSTERING ORDER BY (tc DESC) AND compaction={'class': 'LeveledCompactionStrategy'};
>     create index test4_index ON test4(lname);
> Populate it with some data and non-zero tc values, then try:
>     select * from test4 where lname='blah' and tc>0 allow filtering;
> And, (0 rows) returned, even though there are rows which should be found.
> When I create the table using CLUSTERING ORDER BY (tc ASC), the above query works. Rows are correctly returned based on the range check.
> Tried various combinations but with descending order on tc nothing works.



--
This message was sent by Atlassian JIRA
(v6.2#6252)