cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6950) Secondary index query fails with tc range query when ordered by DESC
Date Fri, 16 May 2014 11:25:03 GMT

    [ 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)

Mime
View raw message