[
https://issues.apache.org/jira/browse/PHOENIX-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor reopened PHOENIX-4322:
-----------------------------------
Can we explore adjusting the RVC row key generation code instead of changing
ScanUtil since this appears to be the only case that sometimes generates a
trailing null byte? I'm a bit nervous to change the ScanUtil code if this is a
very special case as that code is super critical.
Also, it's fine to submit patches that'll kick off a Jenkins run without a code
review (see https://phoenix.apache.org/contributing.html#Local_Git_workflow),
but let's make sure patches get reviewed before committing to branches that
releases come out of. Or we could alternatively change our policy - feel free
to start a discussion thread.
Since we're pretty close to getting a 4.13 release out, I'm going to revert
this for now. FYI, the active release branches are 4.x-HBase-0.98 and master
(which is used for HBase-1.3 releases).
> 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)
