Good catch William, Please raise JIRA and upload patch there. http://issues.apache.org/jira/browse/PHOENIX
Thanks, Rajeshbabu. On Wed, Nov 16, 2016 at 1:59 PM, William <yhxx...@163.com> wrote: > Hi all > This is a very simple case, easy to repro, see the following SQLs: > > > create table tt (pk integer primary key, a integer, b integer); > create index tti on tt (a); > upsert into tt values (1, 2, 3); > select /*+index(tt tti)*/ b from tt where a = 2; // will query > back to data table > //this SELECT works fine, will return b=3 > > create table tt2 (pk integer primary key desc, a integer, b integer); > create index tt2i on tt2 (a); > upsert into tt2 values (1, 2, 3); > select /*+index(tt2 tt2i)*/ b from tt2 where a = 2; > // this SELECT should return the same result set, but actually returned > an empty ResultSet > > The only difference between tt2 and tt is that pk column of tt2 is in > DESC order. But the same SELECT returns nothing for tt2. The reason of this > bug is in HashCacheClient#evaluateKeyExpression(). In line 173, > type.toObject() didn't take sort order as a param. All we have to do is to > pass child.getSortOrder() to type.toObject() method. > > > Just modify this line like this: > values.add(LiteralExpression.newConstant(type.toObject(ptr, > child.getSortOrder()), type)); > > > I checked the code in trunk and this bug still exists. Are there any > similar scenarios that failed considering the sort order information? > > > Thanks. > William
