Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 16 May 2014 11:25:03 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12704312.1396028548580.367477.1400239503072@arcas>
In-Reply-To: <JIRA.12704312.1396028548580@arcas>
References: <JIRA.12704312.1396028548580@arcas>
Subject: [jira] [Commented] (CASSANDRA-6950) Secondary index query fails
 with tc range query when ordered by DESC
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-6950?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13998724#comment-13998724 ]=20

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

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

Well this is the whole question, what behavior is right for thrift :). In t=
hrift we never (to the best of my knowledge) special case code for a specif=
ic AbstractType, and starting doing so now in that case makes me slightly u=
ncomfortable. In particular, the order  in thrift is so far always directly=
 the one of said AbstractType. So does it makes more sense to ignore Revers=
eType 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 breaki=
ng user that rely on the current behavior (that has been here basically for=
ever). 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 leanin=
g towards keeping things the way it is as far as thrift goes just in case s=
omeone relies on it (and if someone using this is bugged by this, he can ea=
sily 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 s=
ome 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-SNAPS=
HOT-src.tar.gz from build #284 (also tried with 2.0.5 with CASSANDRA-6666 p=
atch 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, P=
RIMARY KEY ((name, lname), tc)) WITH CLUSTERING ORDER BY (tc DESC) AND comp=
action=3D{'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=3D'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 que=
ry 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)