[
https://issues.apache.org/jira/browse/PHOENIX-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226282#comment-16226282
]
Maryann Xue commented on PHOENIX-4322:
--------------------------------------
Sorry, [~jamestaylor], for checking that in without code being reviewed. I was
thinking PHOENIX-3050 depended on this issue and the impact of this issue might
be limited.
I first thought the issue lied in RVC evaluation, but found out later that RVC
chooses to kick away the ASC separators but to keep the DESC separators
deliberately. I think it's just trying to match with the way we organize PK
columns into a rowkey. Since there's no way for RVC itself to know what context
it is used in, I thought it would be better to look into the caller, and in
this case, it's the ScanUtil.
The condition I proposed to add to the "if" clause in my patch is now strict
enough I think: we only avoid adding an extra separator if "this current value
is not empty && it's an RVC && its last byte is already the same separator".
> DESC primary key column with variable length does not work in SkipScanFilter
> ----------------------------------------------------------------------------
>
> Key: PHOENIX-4322
> URL: https://issues.apache.org/jira/browse/PHOENIX-4322
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Priority: Minor
> Fix For: 4.13.0
>
>
> Example:
> {code}
> @Test
> public void inDescCompositePK3() throws Exception {
> String table = generateUniqueName();
> String ddl = "CREATE table " + table + " (oid VARCHAR NOT NULL, code
> VARCHAR NOT NULL constraint pk primary key (oid DESC, code DESC))";
> Object[][] insertedRows = new Object[][]{{"o1", "1"}, {"o2", "2"},
> {"o3", "3"}};
> runQueryTest(ddl, upsert("oid", "code"), insertedRows, new
> Object[][]{{"o2", "2"}, {"o1", "1"}}, new WhereCondition("(oid, code)", "IN",
> "(('o2', '2'), ('o1', '1'))"),
> table);
> }
> {code}
> Here the last column in primary key is in DESC order and has variable length,
> and WHERE clause involves an "IN" operator with RowValueConstructor
> specifying all PK columns. We get no results.
> This ends up being the root cause for not being able to use child/parent join
> optimization on DESC pk columns as described in PHOENIX-3050.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
